Malware OSX/Dok intercepta tráfego HTTPS em macOS com proxy malicioso

Campanha de phishing distribuiu um pacote assinado com certificado de desenvolvedor válido, elevou privilégios no sistema e alterou a confiança de certificados para viabilizar interceptação de comunicações protegidas.

Componente	Malware OSX/Dok para OS X/macOS, distribuído em arquivo ZIP chamado Dokument.zip e empacotado como bundle Truesteer.AppStore.
Vetor	E-mails de phishing direcionados a usuários europeus, incluindo isca sobre supostas inconsistências em declaração fiscal, induziam a abertura do pacote malicioso.
Impacto	Após obter a senha do usuário, o malware ganhava privilégios administrativos, instalava certificado raiz fraudulento, configurava proxy e permitia interceptação de tráfego HTTPS por ataque Man-in-the-Middle.
Prioridade	Revogar confiança em certificados suspeitos, revisar itens de login e LaunchAgents, validar configurações de proxy/PAC e remover persistência vinculada ao OSX/Dok.
Artefatos	Cópia em /Users/Shared/, alteração em /etc/sudoers, instalação de brew, Tor e SOCAT, além de uso de PAC hospedado por infraestrutura maliciosa.
IoCs	Hash de amostra 7819ae7d72fa045baa77e9c8e063a69df439146b27f9c3bb10aef52dcc77c145 e endereço onion defangado paoyu7gub72lykuk[.]onion.

Resumo técnico

O OSX/Dok foi observado como uma ameaça voltada a usuários de OS X/macOS, distribuída por campanha coordenada de phishing e assinada com certificado de desenvolvedor válido autenticado pela Apple no momento da análise original. Essa assinatura reduzia a fricção de execução e aumentava a chance de o usuário aceitar o pacote como legítimo. O arquivo malicioso era entregue em um ZIP chamado Dokument.zip, com bundle identificado como Truesteer.AppStore, assinado em 21 de abril de 2017 por um desenvolvedor apresentado como “Seven Muller”.

O objetivo técnico da infecção era obter controle sobre o caminho de rede do usuário e permitir leitura ou adulteração de comunicações protegidas por SSL/TLS. Para isso, o malware combinava engenharia social, persistência local, alteração de privilégios, instalação de ferramentas auxiliares, configuração de proxy e inclusão de um certificado raiz fraudulento no sistema. A cadeia não dependia apenas de exploração silenciosa: ela pressionava o usuário a fornecer a senha administrativa por meio de uma janela sobreposta às demais, apresentada como uma atualização de segurança do sistema operacional.

A campanha foi descrita como voltada principalmente a usuários europeus. Um dos exemplos de isca citava supostas inconsistências em declarações fiscais para atingir um usuário na Alemanha. Esse detalhe é importante para defesa porque desloca a triagem além de anexos genéricos: mensagens com linguagem tributária, anexos ZIP e aparência documental devem ser correlacionadas com eventos de execução de bundles macOS, mudanças de proxy, criação de itens de login e instalação inesperada de certificados raiz.

Fluxo técnico

Após a execução inicial, o OSX/Dok copiava a si mesmo para /Users/Shared/ e passava a executar a partir desse novo local. Em seguida, apresentava uma mensagem falsa informando que o pacote estaria danificado e não poderia ser aberto. Esse erro fabricado servia para reduzir a suspeita imediata do usuário, enquanto a lógica maliciosa continuava a preparar a persistência e a próxima etapa de privilégio.

O malware verificava se já existia um item de login chamado AppStore. Caso encontrasse esse item, removia a entrada e adicionava a si mesmo como novo item de login. Com isso, conseguia iniciar automaticamente a cada reinicialização até concluir a instalação do payload. Essa técnica é relevante para resposta a incidentes porque eventos de persistência com nomes que imitam componentes legítimos da Apple podem passar despercebidos em revisões superficiais, especialmente quando aparecem junto de mensagens de erro aparentemente inofensivas.

A etapa de elevação dependia de uma janela posicionada acima das demais, impedindo a interação normal com o computador. A mensagem alegava que um problema de segurança havia sido identificado no sistema operacional e que uma atualização exigia a senha do usuário. O malware considerava a localização do sistema e suportava mensagens em alemão e inglês, sinal de adaptação da campanha ao público-alvo. Quando a vítima informava a senha, o malware obtinha privilégios administrativos e passava a alterar componentes sensíveis do sistema.

Com privilégios elevados, a ameaça instalava brew e, por meio dele, adicionava ferramentas como Tor e SOCAT. Essas ferramentas eram usadas para compor o caminho de comunicação e redirecionamento necessário à infraestrutura de proxy. O malware também alterava /etc/sudoers para permitir que o usuário atual executasse ações administrativas sob demanda sem novas solicitações de senha. Essa alteração diminuía a quantidade de prompts visíveis e facilitava a continuidade das mudanças privilegiadas sem gerar repetidos alertas para a vítima.

A mudança central ocorria na pilha de rede. O OSX/Dok ajustava as configurações do sistema para encaminhar conexões de saída por um proxy obtido dinamicamente a partir de um arquivo PAC hospedado em servidor malicioso. Em paralelo, instalava um novo certificado raiz no sistema, fazendo com que o navegador e outros componentes passassem a confiar em certificados apresentados pelo operador do ataque. A combinação de PAC, proxy controlado pelo atacante e certificado raiz fraudulento permitia interceptar sessões HTTPS por Man-in-the-Middle, inclusive com possibilidade de ler e modificar tráfego que o usuário acreditava protegido.

Superfície afetada

A ameaça foi descrita como capaz de afetar todas as versões de OS X existentes na época da publicação original. O fator determinante não era uma versão específica do sistema, mas a execução do pacote malicioso e a concessão da senha administrativa pelo usuário. Ambientes com usuários que possuem permissão para instalar software, aceitar prompts de atualização e alterar configurações de sistema têm exposição maior, sobretudo quando controles de aplicação assinada são tratados como garantia suficiente de segurança.

A assinatura com certificado de desenvolvedor válido ampliava o risco operacional porque diminuía a probabilidade de bloqueio inicial por mecanismos que confiam excessivamente na reputação do certificado. Depois que a Apple revogou o primeiro Developer ID associado à campanha, novas variantes foram observadas com outro Developer ID, posteriormente revogado. As variantes também adicionaram uma camada ofuscada com UPX, indicando tentativa de reduzir detecção por produtos de segurança e de manter a campanha ativa após medidas de revogação.

O impacto se concentra em estáções de trabalho macOS usadas para navegação, e-mail, acesso a serviços corporativos, portais financeiros, aplicações SaaS e sistemas internos via HTTPS. Como a interceptação ocorre no endpoint, antes que o usuário perceba alteração visual clara, credenciais digitadas em páginas legítimas, cookies de sessão, respostas de aplicações e dados enviados por formulários podem ficar expostos ao operador do proxy caso a cadeia esteja completa. Esse risco deve ser tratado como comprometimento da confiança local do sistema, não apenas como presença de um aplicativo indesejado.

• Usuários que abriram Dokument.zip ou executaram bundle identificado como Truesteer.AppStore devem ser priorizados para análise.
• Estáções com cópia suspeita em /Users/Shared/ e item de login AppStore recriado exigem verificação de persistência.
• Máquinas com certificado raiz não reconhecido e proxy/PAC configurado sem justificativa administrativa devem ser tratadas como potencialmente interceptadas.
• Ambientes em que usuários locais têm privilégios administrativos apresentam maior risco de conclusão da cadeia maliciosa.

Hunting e telemetria

A investigação defensiva deve começar pela correlação entre eventos de e-mail, abertura de anexos ZIP, execução de aplicativo macOS e mudanças subsequentes em persistência. O nome Dokument.zip é um indicador direto, mas não deve ser a única condição de busca, pois variantes podem alterar nomes de arquivo. O comportamento mais robusto envolve execução a partir de localização compartilhada, criação ou troca de item de login com nome semelhante a componente legítimo e tentativa de bloquear a interação do usuário até a inserção de senha.

No endpoint, a criação de artefatos em /Users/Shared/, modificações em /etc/sudoers, instalação inesperada de brew, Tor e SOCAT, além de novos LaunchAgents, compõem um conjunto forte de sinais. A análise deve comparar horários desses eventos com o primeiro recebimento do e-mail suspeito e com autenticações privilegiadas locais. Em estáções corporativas, mudanças em sudoers devem ser raras e justificadas; qualquer permissão adicionada para reduzir prompts administrativos merece contenção imediata.

Na rede, a defesa deve procurar alterações de proxy, consultas ou conexões associadas a PAC não aprovado, tráfego local envolvendo 127[.]0[.]0[.]1 como etapa de redirecionamento e tentativas de alcançar o endereço onion defangado paoyu7gub72lykuk[.]onion por meio de Tor. Como o tráfego pode passar por componentes locais antes de sair para a infraestrutura controlada pelo operador, a telemetria do endpoint e da configuração de rede costuma ser mais confiável que inspeções baseadas apenas em perímetro.

• Presença do hash de amostra 7819ae7d72fa045baa77e9c8e063a69df439146b27f9c3bb10aef52dcc77c145 em quarentena, EDR ou inventário forense.
• Criação ou substituição de item de login chamado AppStore após execução de anexo ZIP.
• Instalação de certificado raiz não autorizado próxima a mudanças de proxy ou PAC.
• Alterações em /etc/sudoers para reduzir solicitações de senha administrativa.
• Instalação não planejada de brew, Tor ou SOCAT em estáções de usuários finais.

Mitigação

A resposta deve tratar a estáção afetada como um endpoint com confiança criptográfica comprometida. Remover apenas o aplicativo não é suficiente se o certificado raiz, a configuração de proxy, os LaunchAgents e as alterações de privilégio permanecerem. A ordem recomendada é isolar a máquina da rede, preservar evidências relevantes, remover persistência, reverter alterações em proxy/PAC, excluir certificados raiz não autorizados, validar /etc/sudoers e revisar itens de login criados ou modificados no período do incidente.

Depois da limpeza, credenciais usadas durante a janela de possível interceptação devem ser redefinidas, com atenção especial a contas corporativas, e-mail, VPN, serviços financeiros, painéis administrativos e aplicações SaaS acessadas pelo usuário. Sessões ativas devem ser invalidadas quando o serviço permitir. A razão é simples: se o proxy malicioso operou com um certificado confiado localmente, autenticações e tokens trafegados em HTTPS podem ter sido observados ou modificados sem erro visível no navegador.

No controle preventivo, organizações devem reduzir a dependência de confiança implícita em assinatura de desenvolvedor, aplicar políticas de allowlist para software, restringir privilégios administrativos locais e monitorar alterações de certificados raiz. Gateways de e-mail devem tratar anexos ZIP com aplicativos macOS como alto risco, especialmente quando combinados com temas fiscais, urgência de correção ou mensagens localizadas para o país do usuário. A revogação de certificados pela Apple reduz a exposição futura, mas não corrige sistemas já modificados pela cadeia de infecção.

• Isolar hosts suspeitos antes de remover artefatos, para preservar linha do tempo e evitar novas interceptações.
• Remover certificados raiz desconhecidos e confirmar que a loja de confiança voltou ao estado aprovado pela organização.
• Reverter configurações de proxy e PAC não autorizadas, incluindo dependências que apontem para serviços locais ou infraestrutura Tor.
• Auditar /etc/sudoers, itens de login e LaunchAgents para eliminar persistência e privilégios indevidos.
• Redefinir senhas e revogar sessões de contas usadas no período em que o proxy malicioso pode ter operado.