ClickLock: novo infostealer para macOS mata apps a cada 210ms para forcar vitima a digitar a senha

Um novo infostealer para macOS chamado ClickLock transformou a persistência agressiva em arma de coerção: quando a vítima cancela o falso diálogo de sistema, dois LaunchAgents disparam um loop que mata Finder, Dock, Spotlight, Terminal, Activity Monitor e navegadores a cada 210 milissegundos por até 83 horas — deixando na tela apenas uma caixa de senha em um desktop morto. Group-IB rastreou pelo menos 100 vítimas em 33 países desde maio, mais da metade na Europa, com o orquestrador subindo ao VirusTotal em 9 de junho e zero detecções na data da análise.

O que aconteceu

Pesquisadores da Group-IB documentaram uma campanha ativa de um infostealer inédito para macOS que abandona o roteiro clássico dos stealers da família Atomic, Poseidon e Cthulhu. Em vez de tentar sequestrar a sessão com um único prompt e desistir se o usuário negar, o ClickLock desenha um cenário em que negar é pior do que ceder: o loop de coerção só para quando a senha do login é digitada.

A cadeia começa em uma página de lure ainda não identificada. A vítima é induzida a copiar e colar um comando no Terminal — o padrão ClickFix, já amplamente explorado por operadores de commodity malware em Windows e agora consolidado no ecossistema Apple. O script exibe um diálogo de sistema falsificado pedindo a senha. Se o usuário aceitar, o roubo é imediato. Se cancelar, o orquestrador instala silenciosamente dois arquivos plist em ~/Library/LaunchAgents/ e encerra a execução aparente.

No próximo login, o inferno começa. Os LaunchAgents com.authirity.plist e com.chromer.plist disparam laços paralelos que matam processos críticos do sistema em intervalos de 200 a 210 milissegundos. Um deles pode persistir por até 3.000.000 de segundos — cerca de 34,7 dias — enquanto um processo em segundo plano consulta o Keychain a cada meio segundo pela chave Safe Storage do Chrome, forçando o macOS a levantar prompts de autorização reais até que a vítima finalmente digite a senha.

Como o ataque funciona

O desenho técnico do ClickLock é chocantemente pragmático. O primeiro loop, ativado por com.authirity.plist, executa o ciclo de morte de processos em intervalos de 210 ms até que uma senha válida seja capturada. O segundo, disparado por com.chromer.plist, mantém intervalos de 0,2 segundo por até 34,7 dias. Terminal e Activity Monitor estão nas duas listas de kill, o que impede diagnóstico manual. Um terceiro loop mata o NotificationCenter por seis horas, cancelando qualquer alerta de Gatekeeper.

Se o Terminal não tem Full Disk Access — condição necessária para varrer diretórios sensíveis —, o orquestrador abre o painel exato de System Settings e guia a vítima pelo processo de concessão do privilégio. O malware não invade o sistema; ele obriga o usuário a abrir a porta em nome dele.

“O usuário que se recusa a colaborar não é um caso extremo. É exatamente o que o design contempla.”

Group-IB, análise técnica do ClickLock Stealer

Uma vez capturada a senha, o operador recebe o pacote completo: chave Safe Storage AES do Chrome (que decifra credenciais e cookies armazenados no disco, mesmo offline, na máquina do atacante), Keychain do usuário, cofres de gerenciadores de senha, extensões de carteiras cripto do navegador, arquivos de carteiras desktop, histórico de shell e credenciais salvas do FileZilla. A chave do Safe Storage é o ativo de maior valor — permite exfiltração persistente das credenciais mesmo depois que a vítima trocar a senha do sistema, se não revogar sessões ativas.

Quem é afetado

A telemetria do Group-IB aponta pelo menos 100 alvos confirmados em 33 países, com concentração na Europa (mais de 50%). O malware ainda estaria em desenvolvimento, segundo indícios no código, o que sugere que a campanha atual é apenas um piloto. Três hosts de payload comprometidos estão nos IOCs; nenhum domínio de lure foi identificado — o que significa que o vetor inicial (phishing, redes sociais, torrents ou anúncios pagos) continua ativo e não mapeado.

• Usuários macOS que executam comandos vindos de páginas de “solução de erro” (padrão ClickFix)
• Profissionais que usam Chrome com Safe Storage e carteiras cripto no navegador
• Empresas com endpoints Apple sem EDR configurado para detectar plists suspeitos em LaunchAgents
• Freelancers e desenvolvedores que operam com FileZilla salvando credenciais SFTP em texto
• Qualquer ambiente que trate a “recusa do usuário” como suficiente para conter uma infecção

Análise

O ClickLock representa uma mudança de paradigma em stealers para macOS. Até o Atomic Stealer, o padrão era otimista: se o usuário nega, o operador perde a vítima. O ClickLock parte do pressuposto inverso — a maioria dos usuários que executa o comando inicial não vai reconhecer o segundo prompt como malicioso, e mesmo os que reconhecem cederão sob pressão. É um design de negação de serviço aplicado ao endpoint do próprio usuário, transformando a recusa em custo psicológico intolerável.

Vale comparar com o padrão Nightmare Eclipse observado no Windows, onde loops de UAC bypass usam a fadiga do usuário para arrancar consentimento. A técnica migrou. Em macOS, onde o modelo TCC de permissões depende quase exclusivamente do julgamento do dono da máquina, o vetor de coerção é potencialmente mais efetivo. O fato de o orquestrador ter subido ao VirusTotal sem detecção reforça a limitação estrutural: assinaturas estáticas não capturam intenção comportamental.

A ausência da página de lure é o dado mais preocupante. Sem entender o vetor de entrega, times de resposta ficam presos a caçar plists e processos de kill, mas não conseguem cortar o funil. Historicamente, ClickFix vem sendo entregue por meio de resultados patrocinados no Google, tutoriais falsos no YouTube e páginas de captcha falsas — todas replicáveis a baixo custo. Se o ClickLock está em desenvolvimento ativo, a próxima onda tende a incluir polimorfismo no orquestrador e evasão de Endpoint Security via injeção em processos assinados.

Recomendações práticas

• Bloquear via política a execução de comandos oriundos do clipboard em terminais de usuários finais — considerar restrições MDM que exigem revisão por privilégio elevado
• Monitorar criação e alteração de arquivos em ~/Library/LaunchAgents/ como sinal de alta prioridade; nomes suspeitos incluem com.authirity.plist e com.chromer.plist
• Instrumentar EDR/XDR para detectar padrões de kill loop (dezenas de SIGKILL contra processos específicos em intervalos submilissegundos)
• Revisar quem tem Full Disk Access no ambiente e por quê; remover concessões antigas ao Terminal
• Adotar gerenciadores de senha com proteção biométrica em vez de confiar no Keychain nu; migrar carteiras cripto para hardware wallets
• Em caso de suspeita de infecção: revogar sessões ativas nos navegadores imediatamente, tratar toda senha salva como comprometida, girar chaves de API e credenciais SFTP, e considerar reinstalação limpa do sistema
• Treinar times de suporte para reconhecer o padrão “meu Mac está travando e pedindo minha senha” como possível indicador de comprometimento, não bug de sistema

Fonte: The Hacker News