Acabou o WannaCry: indicadores de comprometimento do worm de ransomware, Tor C2 e análise técnica + regras de SIEM
Índice:
Boas notícias a todos!
Após um dia, noite e manhã bastante longos estudando as notícias, pesquisando e caçando o ransomware WannaCry, há algumas descobertas a serem compartilhadas. Isso inclui IOCs de Host e Rede, suas análises obtidas com a ajuda de colegas pesquisadores de segurança e praticantes, revisão da infraestrutura C2 e suas interações com o Tor. Por último, mas não menos importante, alguns casos de uso gratuito de SIEM que podem ajudar imediatamente a detectar e começar a bloquear o desastre mencionado acima de escalar. E há uma revisão rápida das assinaturas SIGMA que acabei de descobrir recentemente (Yara para SIEM). Aviso: o objetivo deste post é fornecer IOCs e orientação sobre como detectar e bloquear a ameaça de ransomware WannaCry aproveitando ferramentas de SIEM, OSINT, firewalls, proxies/portais de segurança e fazer tudo isso no menor tempo possível. Isso não é uma análise reversa de malware ou um artigo de mídia, há um grande trabalho feito nesse aspecto por muitas pessoas já (vocês sabem quem são, obrigado pela ajuda!).
Análise macro
Caso você tenha perdido toda a explosão da mídia sobre o surto do ransomware WannaCry/WannaCrypt que atingiu o mundo na sexta-feira, 12 de th2017, esses 2 artigos de alto nível se destacam para mim como os mais abrangentes e fáceis de entender dos cerca de 40 que li até agora: forbes.com, blog.qualys.com.
E um registro de mapa de ataque pela MalwareTech que assumiu o controle de um dos domínios do malware.
Mas por que não o Cisco Talos? Aqui está o link http://blog.talosintelligence.com/2017/05/wannacry.html, mas esse artigo é uma leitura longa e levanta questões na parte técnica (continue lendo para ver por que). E se você está lendo isso, significa que estamos juntos na resolução da natureza técnica deste incidente e na prevenção de que ele e ataques semelhantes aconteçam no futuro.
Concluindo a análise macro, de um colega de segurança:“Justo, mas meu ponto real é que, agora que as ferramentas de hacking da CIA/NSA foram vazadas, estou certo de que isso acontecerá novamente… as empresas precisarão ser proativas, consultar seus CMDB e localizar esses sistemas fora de suporte, e atualizá-los rapidamente, fortalecê-los desativando quaisquer serviços Windows não essenciais, e submeter os mais críticos para teste de penetração de terceiros… se o negócio optar por ‘aceitar o risco’ (para evitar o custo), é justo que o risco seja totalmente explicado para eles.”
Vamos à parte divertida!
IOCs de Rede e sua usabilidade
No que diz respeito ao OSINT, conseguimos desenterrar 39 endereços IP, às vezes com portas, protocolos e comentários. Isso veio da McAfee, Cisco Talos e uma amostra do sandbox Payload Security. Todos sabemos que um IP por si só não é um bom #threatintel, então vamos fazer uma análise do que vemos e como isso pode nos ajudar a Detectar e Bloquear o WannaCry/WannaCrypt ou qualquer coisa que seja #wannamesswithourproperty. Cada IP foi pingado, analisado via VirusTotal e com o feed DetectTor da SOCPrime. Este último é uma coleção de 1,5 anos de atividade da rede Tor que é coletada em tempo real. Tabela inicial para sua referência.
IP | Porta | Proto | Fonte | Geo | ASN | Organização | Tipo Tor | Status VT |
104.131.84.119 | 443 | McAfee | US | 393406 | Digital Ocean | Nó de Saída | Limpo | |
128.31.0.39 | 9101 | TCP | Payoad Security | US | 3 | MIT | Nó de Saída | Malicioso |
128.31.0.39 | Cisco Talos | Yes | Malicioso | |||||
136.243.176.148 | 443 | TCP | Payoad Security | DE | 24940 | Hetzner Online AG | Nó de Saída | Malicioso |
146.0.32.144 | 9001 | Cisco Talos | DE | 24961 | myLoc managed IT AG | Nó de Saída | Malicioso | |
163.172.153.12 | 9001 | TCP | Payoad Security | GB | ONLINE SAS | Yes | Malicioso | |
163.172.185.132 | 443 | TCP | Payoad Security | GB | ONLINE SAS | Yes | Malicioso | |
163.172.25.118 | 22 | McAfee | GB | Yes | Malicioso | |||
163.172.35.247 | 443 | TCP | Payoad Security | FR | ONLINE SAS | Saída, Guardião | Talvez limpo | |
171.25.193.9 | 80 | TCP | Payoad Security | SE | 198093 | Foreningen for digitala fri- och rättigheter | Nó de saída | Malicioso |
178.254.44.135 | 9001 | McAfee | DE | 42730 | EVANZO e-commerceGmbH | Nó de Saída | Malicioso | |
178.62.173.203 | 9001 | TCP | Payoad Security | NL | 200130 | Digital Ocean | Nó de Saída | Malicioso |
185.97.32.18 | 9001 | TCP | Payoad Security | SE | 44581 | AllTele Allmanna Svenska Telefonaktiebolaget | Nó de Saída | Malicioso |
188.138.33.220 | Cisco Talos | DE | 8972 | intergenia AG | Malicioso | |||
188.166.23.127 | 443 | Cisco Talos | NL | 202018 | Digital Ocean | Nó de Saída | Malicioso | |
192.42.115.102 | 9004 | McAfee | NL | 1103 | SURFnet | Nó de Saída | Malicioso | |
193.23.244.244 | 443 | Cisco Talos | DE | 50472 | Chaos Computer Club e.V. | Nó de Saída | Malicioso | |
198.199.64.217 | 443 | McAfee | US | 46652 | ServerStack | Nó de Saída | Malicioso | |
2.3.69.209 | 9001 | Cisco Talos | FR | 3215 | Orange | Nó de Saída | Limpo | |
212.47.232.237 | Cisco Talos | FR | 12876 | Tiscali France | Nó de Saída | Malicioso | ||
213.239.216.222 | 443 | McAfee | DE | 24940 | Hetzner Online AG | Nó de Saída | Malicioso | |
213.61.66.116 | 9003 | TCP | Payoad Security | DE | 8220 | COLT Technology Services Group Limited | Nó de Saída | Malicioso |
213.61.66.116 | Cisco Talos | DE | 8220 | COLT Technology Services Group Limited | Nó de Saída | Malicioso | ||
217.172.190.251 | 443 | TCP | Payoad Security | DE | 8972 | intergenia AG | Nó de Saída | Limpo |
217.79.179.77 | Cisco Talos | DE | 24961 | myLoc managed IT AG | Limpo | |||
38.229.72.16 | Cisco Talos | US | 23028 | Team Cymru | Malicioso | |||
50.7.151.47 | 443 | TCP | Payoad Security | US | 174 | FDCservers.net | Nó de Saída | Malicioso |
50.7.161.218 | 9001 | Cisco Talos | NL | 174 | FDCservers.net | Nó de Saída | Malicioso | |
51.255.41.65 | 9001 | McAfee | FR | 16276 | OVH SAS | Nó de Saída | Malicioso | |
62.138.10.60 | 9001 | McAfee | DE | 61157 | Heg mas | Nó de Saída | Malicioso | |
62.138.7.231 | 9001 | TCP | Payoad Security | DE | 61157 | Heg mas | Nó de Saída | Malicioso |
79.172.193.32 | Cisco Talos | HU | 29278 | Deninet KFT | Nó de Saída | Malicioso | ||
81.30.158.223 | Cisco Talos | DE | 24961 | myLoc managed IT AG Vserver Netz | Nó de Saída | Malicioso | ||
82.94.251.227 | 443 | McAfee | NL | 3265 | XS4ALL Internet BV | Nó de Saída | Malicioso | |
83.162.202.182 | 9001 | TCP | Payoad Security | NL | 3265 | XS4ALL Internet BV | Nó de Saída | Malicioso |
83.169.6.12 | 9001 | McAfee | DE | 20773 | Host Europe GmbH | Nó de Saída | Malicioso | |
86.59.21.38 | 443 | McAfee | AT | 3248 | Tele2 Telecommunication GmbH | Nó de Saída | Malicioso | |
89.45.235.21 | Cisco Talos | SE | 1653 | SUNET/NORDUnet | Yes | Malicioso | ||
94.23.173.93 | 443 | TCP | Payoad Security | FR | 16276 | OVH.CZ s.r.o. | Nó de Saída | Malicioso |
Então o que vemos? 36 dos 39 IPs ou 92% dos endereços C2 relatados são, veja só! Nós do Tor. E 37 IPs são marcados como maliciosos pelo VirusTotal dentro de dias ou 1,5 meses dos incidentes e isso é 87%. Mas por que vemos quase nenhuma porta? Vamos analisar mais profundamente, não há tempo para desenhar uma imagem bonita (também minhas habilidades de desenho são ruins) então vou compartilhar 2 imagens de outra tabela .XLS:
Qual é o problema com as tabelas e cores? Para nomear algumas coisas:
1) Há apenas 1 Ponte Tor Oculta (laranja). Isso significa que o atacante estava com pressa para lançar as coisas e provavelmente é um cibercriminoso e não um ator APT patrocinado pelo Estado (a menos que seja um plano de engano ultra sofisticado para fingir que você não é um ator APT). Se compararmos este surto a campanhas APT sérias, as pontes Tor Ocultas tornam a infraestrutura muito mais furtiva e difícil de lidar, também mais cara.
2) O transporte usado em todos os nós Tor não é ofuscado e não utiliza os modernos Tor meek e Obfs4. Isso significa que o tráfego é relativamente fácil de distinguir em ambientes corporativos, você nem precisa de um DPI para fazer isso.
3) Todos os IPs relatados foram comparados com o Detect Tor que tem mais de 18 meses de histórico de nó, transporte e reputação de Tor. Isso nos permite descobrir portas usadas por nós Tor e atribuí-los, enriquecendo assim os IOCs. Além disso, você pode encontrar nós frescos (31 e 37), apenas 2 dos 39, isso significa que não houve uma nova infraestrutura Tor especial lançada para o ataque – a rede Tor existente foi usada com domínios C2 ocultos no web .onion.
4) Nos C2 relatados, 13 portas, ou seja, 33% são 443 e 13 são 9001 (porta Tor padrão) e 3 outras são portas 900X. Com redes devidamente segmentadas, conexões de saída para a porta 9001 não passarão de nenhum segmento da maioria das empresas. No conjunto de dados enriquecido, lidamos com 59 portas, com as portas 443 e 9001 representando 59% de todas as portas. Também vemos que 4 IPs relatados pelo Talos não têm portas, no entanto, estão ativos a partir de 13.05.17 e descobrimos as portas.
5) #28, 38 e 39 não são nós Tor, porém são marcados como Maliciosos pelo VirusTotal e nenhuma porta relatada novamente por Talos. Esses são provavelmente sites de distribuição.
6) #62 é um falso positivo relatado por Talos, pois leva ao deb.torproject.org e outros múltiplos subdomínios do Torproject que são bastante benignos – eles hospedam o navegador Tor, o que não os torna um C2 ou site malicioso.
Então, o que fazer com as informações de C2? Você pode usá-las como IOC codificado para as próximas 1-2 semanas, mas sua precisão degradará a cada hora que passa. O mais importante é que a rede C2 está totalmente por trás do Tor e, ao criar listas negras ao vivo no perímetro corporativo e dispositivos de endpoint, podemos prevenir o tráfego C2 por completo. Pelo menos para essa variável do worm de ransomware wannacry?, já que as capacidades de tunelamento DNS não foram relatadas no momento dessa escrita.
IOCs Baseados em Host:
Há uma assinatura SIGMA criada pelo autor do projeto Florian Roth no github: github.comCitação do site do projeto “Sigma é um formato de assinatura genérico e aberto que permite descrever eventos de logs relevantes de maneira direta. O formato da regra é muito flexível, fácil de escrever e aplicável a qualquer tipo de arquivo de log. O principal objetivo deste projeto é fornecer uma forma estruturada na qual os pesquisadores ou analistas possam descrever seus métodos de detecção uma vez desenvolvidos e torná-los compartilháveis com outros.
Sigma é para arquivos de log o que o Snort é para o tráfego de rede e o YARA é para arquivos.
Os casos de uso incluem:
- Descreva seu método de detecção descoberto uma vez no Sigma para torná-lo compartilhável
- Compartilhe a assinatura no apêndice de sua análise junto com hashes de arquivos e servidores C2
- Compartilhe a assinatura em comunidades de inteligência de ameaça – por exemplo, via MISP
- Forneça assinaturas Sigma para comportamento malicioso em sua própria aplicação (Mensagens de Erro, violações de acesso, manipulações)
- Integre um novo log em seu SIEM e verifique o repositório Sigma para regras disponíveis
- Escreva um conversor de regras para sua ferramenta de análise de logs personalizada e processe novas regras Sigma automaticamente
- Forneça um feed gratuito ou comercial para assinaturas Sigma”
Estamos trabalhando em conjunto com a equipe Sigma para expandir as capacidades para mais tecnologias SIEM.
Você pode encontrar mais IOCs baseados em host no sandbox da Payload Security aqui: hybrid-analysis.comIOCs adicionais baseados em host estão sendo preparados e serão incluídos no artigo nas próximas 24 horas.
Mitigação, também conhecida como CryNoMore
- Sem acesso de entrada ou saída ao Tor das instalações corporativas. Use ACLs em FW/NGFW, portais de segurança/proxies e DNS RPZ se você tiver DNS Unix. Você pode obter o feed do Tor de OSINT ou do nosso UCL, reveja e registre-se aqui my.socprime.com/en/ucl/tor/ , o caso de uso agora é gratuito para sempre para todas as organizações empresariais e do setor público. Isso bloquearia a maior parte das comunicações de entrega e C2.
- Tem um sistema operacional MS desatualizado e não pode aplicar patches? Use isso como uma correção rápida “dism /online /norestart /disable-feature /featurename:SMB1Protocol” ou qualquer método preferido para desativar os serviços SMB. Ideia da fonte:
- Aplique o patch MS17-010 se ainda não o fez:technet.microsoft.comE aplique patches contra todos os exploits revelados pelo Shadow Brokers o mais rápido possível. Precisa de ajuda para medir o risco? Escaneie a rede com Qualys, Tenable ou qualquer ferramenta que compreenda IDs CVE. A lista de CVEs pode ser obtida aqui:https://github.com/misterch0c/shadowbroker
- Tem SMB no perímetro? Então você provavelmente já está criptografado 🙁 Use Shodan para encontrar portas abertas no seu perímetro, é gratuito. Embora o mapeamento e a varredura contínuos de portas sejam melhores, até o bom e velho NMAP pode fazer o trabalho.
- Se você verificar cada conexão de porta 443 de saída com o VirtusTotal, provavelmente bloquearia >87% do tráfego de C2 nesse ataque. Pense nisso.
- Como regra geral, pergunte a si mesmo: por que você permite tráfego de saída para a porta 9001 de qualquer maneira? Ou de fato para qualquer porta exceto 80 e 443.
- Bloqueie todas as solicitações de saída na porta 80 e 443 para endereços IP que não resolvem em um domínio. Você pode ser mais criativo e limitar isso com uma lista de permissões do Alexa top 1M e excluir sub-redes dsl/internet residencial/internet móvel. Se você tiver um gateway de segurança web avançado, bloqueie o acesso não apenas a todas as URLs maliciosas, mas também às não categorizadas.
- Ainda abrindo anexos desconhecidos em e-mails que você não esperava? Não faça isso. Simplesmente não.
P.S. As últimas 48 horas foram um inferno de “diversão”: primeiro procurei no meu laptop de dentro para fora por backdoor HP nos drivers de áudio e não encontrei nenhum. Então, de repente, descobri que o MS17-010 não foi instalado corretamente na minha máquina… Então, aqui estamos, a transição do “Confie, mas verifique” da velha escola para o lema do Cyber 2.0 de “Nunca confie e sempre verifique”. Nunca foi tão certo, hora de viver por isso.
/Mantenha-se seguro. E teste seus backups regularmente.
Credits:
Florian Roth and Tom U. for sharing hosts IOCs, developing and supporting SIGMA initiative for SIEM rules
Aleks Bredikhin for waking up late night and starting the update on ArcSight use case.
If you read this far, here are the links to all mentioned goodies:
ArcSight rule package:at Use Case Library https://ucl.socprime.com/use-case-library/info/403/ e no Protect724: https://www.protect724.hpe.com/docs/DOC-15255Pacote Splunk na Use Case Library https://ucl.socprime.com/use-case-library/info/405/Pacote QRadar na Use Case Library https://ucl.socprime.com/use-case-library/info/404/Assinatura SIGMA que pode ser convertida para Splunk, Elastic e LogPoint: https://github.com/Neo23x0/sigma/blob/master/rules/windows/sysmon/sysmon_malware_wannacrypt.ymlAssinatura SIGMA que pode ser convertida para Splunk, Elastic e LogPoint:github.comResultados da sandbox de segurança de payload com IOCs e indicadores de comportamento:hybrid-analysis.com
Curtir / Compartilhar / Comentar / Convidar para discutir
CSV:WannaCry_IOCs_fontes públicas e VTCSV:WannaCry_IOCs_verificação cruzada com feed Tor