634 Palavras-passe em 56 Segundos

Um programador — consciente em termos de segurança, experiente, alguém que procura ativamente esquemas — passou por um processo de entrevistas multifase com uma empresa falsa. Chamada de RH. Entrevista técnica com dois engenheiros. Site real com fotografias da equipa. Perfis reais no LinkedIn. Semanas de construção de confiança.

Depois pediram-lhe para executar um pequeno desafio de programação durante uma partilha de ecrã.

56 segundos depois, os atacantes tinham 634 palavras-passe guardadas no Chrome, o ficheiro da Keychain do macOS (que contém a chave para as desencriptar) e os dados da carteira MetaMask.

Como funcionou o ataque

O repositório do GitHub parecia limpo. Alguns ficheiros de backend, nada de suspeito. Mas uma dependência — winston-middleware, um pacote de logging com um nome perfeitamente normal — tinha uma dependência própria: next-runtimejs.

Foi aí que estava a arma.

No momento em que npm install foi executado, um shell script correu em silêncio. Sem avisos, sem alertas. Descarregou uma porta-traseira escrita em Go e registou-a para arrancar automaticamente em cada boot.

Isto não era uma ferramenta de script kiddie. Protocolo C2 personalizado e encriptado com RC4. Comandos para execução de shell, roubo de ficheiros, extração de palavras-passe do Chrome, exfiltração da Keychain e ataques a carteiras de criptomoedas. Construído de forma profissional.

A porta-traseira iniciou-se às 16:16:37. As palavras-passe do Chrome foram acedidas às 16:17:33. O programador reparou num popup do macOS sobre uma ligação de saída e desligou o WiFi em menos de um minuto — mas o dano já estava feito.

Porque foi importante a entrevista

Este ataque falharia como email a frio. "Corre este repo" vindo de um desconhecido é ignorado.

Mas depois de duas rondas de entrevistas? Depois de rirem juntos sobre quantos esquemas de empregos falsos visam programadores? Depois de um dos entrevistadores dizer, com um sorriso, "Sinta-se à vontade para procurar porta-traseiras"?

É nesse momento que a guarda baixa. A confiança é a vulnerabilidade. O malware é apenas o payload.

O programador resumiu-o da melhor forma: "Se aconteceu a mim, pode acontecer a qualquer pessoa na vossa equipa."

O que as palavras-passe do Chrome representam na verdade

O Chrome encripta as palavras-passe guardadas com AES. A chave de desencriptação está guardada na Keychain do macOS. Os atacantes roubaram ambos os ficheiros em menos de um minuto.

Todas as palavras-passe guardadas — bancos, email, GitHub, consolas de cloud — estavam legíveis do lado deles. O ficheiro da Keychain pode ser quebrado offline, sem limites de tentativas. O programador teve de alterar tudo.

Este é o segredo sujo das palavras-passe guardadas no browser: são encriptadas com uma chave que vive na mesma máquina. Comprometa a máquina, e a "encriptação" é decoração.

O padrão DPRK

O programador mencionou que a sua empresa anterior também tinha sido hackeada pela Coreia do Norte três meses antes. Esta é a campanha "Contagious Interview" — atacantes patrocinados pelo Estado norte-coreano que conduzem entrevistas de emprego falsas para instalar malware em máquinas de programadores.

Não é aleatório. Visam programadores especificamente pelo acesso que estes têm: credenciais de produção, chaves de assinatura, infraestrutura de cloud e — cada vez mais — tokens de agentes de IA que dão acesso a ainda mais.

A escala é industrial. Empresas falsas com rostos gerados. Sites polidos. Processos de entrevista de várias semanas. Investem porque o retorno existe.

"Os gestores de palavras-passe não ajudam"

O programador fez uma afirmação interessante na thread: "Os gestores de palavras-passe não ajudam se eles têm acesso ao seu computador através de uma porta-traseira destas, porque depois podem transmitir qualquer ficheiro, criar um exploit específico para si, keyloggers, capturas de ecrã."

Isto está parcialmente certo e parcialmente errado.

Um gestor de palavras-passe que guarda o seu cofre no disco local, desbloqueado por uma palavra-passe mestra que você escreve — sim, uma porta-traseira com registo de teclas e acesso a ficheiros pode comprometer isso.

Mas um gestor de palavras-passe com chaves ligadas a hardware — em que a chave de desencriptação é derivada de um autenticador físico e nunca existe como ficheiro em disco — é fundamentalmente diferente. A porta-traseira pode roubar ficheiros, registar teclas, tirar capturas de ecrã. Mas não consegue extrair uma chave que só existe dentro de um módulo de segurança de hardware durante uma interação física.

As 634 palavras-passe do Chrome foram roubadas porque tanto os dados encriptados como a chave de desencriptação eram ficheiros no sistema de ficheiros. Se a chave de desencriptação exigir a posse física de um dispositivo, roubar ficheiros dá-lhes blocos encriptados e mais nada.

O que fazer

• Nunca corra código de entrevistas na sua máquina principal. Use uma VM ou um dispositivo separado.
• Execute npm install --ignore-scripts em qualquer repositório desconhecido antes de o executar
• Use uma firewall de saída (Little Snitch, LuLu) que alerte sobre novas ligações
• Pare de guardar palavras-passe no Chrome. Ponto final.
• Mantenha as criptomoedas em carteiras de hardware, não em extensões de browser
• Trate cada desafio de programação vindo de um recrutador como potencialmente hostil, independentemente de quantas chamadas já tenham tido

O programador sobreviveu porque um popup do macOS apanhou a ligação de saída a tempo. A maioria das pessoas teria clicado em Permitir sem pensar duas vezes.

56 segundos. É tudo o que é preciso.