Tínhamos duas assinaturas comerciais do APT, dez trocas de informações, cerca de dez feeds gratuitos e a lista de nós de saída de Thor. E também cinco reversores fortes, um mestre em scripts do PowerShell, um scanner loki e uma assinatura paga do virustotal. Não é que, sem isso, o centro de monitoramento não funcione, mas se você está acostumado a receber ataques complexos, precisa percorrer todo esse caminho até esse hobby. Acima de tudo, estávamos preocupados com a potencial automação da verificação de indicadores de comprometimento. Não há nada mais imoral do que inteligência artificial, substituindo uma pessoa no trabalho onde você precisa pensar. Mas entendemos que, com um aumento no número de clientes, mais cedo ou mais tarde entraríamos nele.
Muitos dizem que a Inteligência de Ameaças é deliciosa, mas nem todos sabem como cozinhá-la. Menos ainda, que entendem quais processos precisam ser construídos para que a TI funcione e traga lucro. E muito poucas pessoas sabem como escolher um provedor de feeds, onde verificar o indicador de quedas e se é necessário bloquear o domínio que o colega enviou ao WhatsApp.
Por vários anos de trabalho constante com a TI, conseguimos caminhar em diferentes ancinhos e hoje queremos dar alguns conselhos práticos que ajudarão os iniciantes a evitar erros.
Dica número 1. Não há grandes esperanças de capturar um hash: a maioria dos malwares há muito tempo é polimórfica
No último artigo, falamos sobre o que é TI e demos alguns exemplos de como o processo de trabalho é organizado. Deixe-me lembrá-lo de que as informações sobre ameaças (inteligência de ameaças) são fornecidas em diferentes formatos e modos de exibição: podem ser os endereços IP dos centros de controle de botnet, os endereços de email dos remetentes dos emails de phishing e os artigos que descrevem as técnicas de desvio de segurança que o APT agrupa -que começará a usar. Em geral, muitas coisas acontecem.
Para otimizar toda essa desgraça, há alguns anos, David Bianco propôs a chamada
"pirâmide da dor" . Descreve muito bem a relação entre os tipos de indicadores que você usa para detectar o invasor e quanta dor você trará ao invasor, se conseguir detectar um tipo específico de indicador.
Por exemplo, se você conhece o hash MD5 de um arquivo malicioso, ele pode ser facilmente detectado e detectado com precisão. No entanto, isso trará muito pouca dor ao invasor - basta adicionar 1 bit de informação ao arquivo e o hash já é diferente.
Dica número 2. Tente usar esses indicadores, cuja mudança será difícil técnica ou economicamente não lucrativa para o invasor
Antecipando a questão de como descobrir se existe um arquivo com esse hash nas estações de trabalho de nossa empresa, respondo: existem maneiras diferentes. Um dos mais fáceis é instalar o Kaspersky Security Center, que contém um banco de dados de hashes MD5 de todos os arquivos executáveis da empresa, nos quais você pode fazer o SELECT.
Vamos voltar à pirâmide da dor. Ao contrário da detecção de hash, será mais produtivo se você puder detectar o TTP (tática, técnica, procedimento) do atacante. É mais complicado e requer mais esforço, mas você sentirá mais dor.
Por exemplo, se você souber que um grupo APT voltado para o seu setor da economia distribui e-mails de phishing com arquivos * .HTA, o desenvolvimento de uma regra de detecção que pesquisa arquivos no correio com anexos semelhantes afetará muito o invasor. Ele terá que mudar as táticas de correspondência, talvez até mesmo investir US $ $ na compra de explorações de 0 ou 1 dia, e isso não é barato ...
Dica número 3. Não tenha grandes esperanças em relação às regras de detecção que não foram desenvolvidas por você; elas deverão ser verificadas quanto a falsos positivos e modificadas
Ao desenvolver regras de detecção, é sempre tentador usar regras predefinidas. Um exemplo gratuito é o repositório
Sigma , um formato de regra de detecção independente do SIEM que converte regras do Sigma em consultas ElasticSearch e regras Splunk ou Arcsight. Ao mesmo tempo, o repositório contém cerca de 200 regras, das quais ~ 130 descrevem ataques ao Windows. À primeira vista, é muito legal, mas o diabo, como sempre, está nos detalhes.
Vamos dar uma olhada em
uma das regras de detecção mimikatz
em detalhes:
A regra detecta processos que tentaram ler a memória do processo lsass.exe. O Mimikatz faz isso quando tenta obter os hashes NTLM e a regra detecta malware.
No entanto, para nós, como especialistas envolvidos não apenas na detecção, mas também na resposta a incidentes, é extremamente importante que isso seja realmente mimikatz. Infelizmente, na prática, existem muitos outros processos legítimos que lêem a memória do lsass.exe com as mesmas máscaras (alguns antivírus, por exemplo). Portanto, em um ambiente de combate real, essa regra trará mais falsos positivos do que bons.
Existem incidentes ainda mais interessantes relacionados à tradução automática de regras das regras Sigma para SIEM:
Em um dos seminários on-line, colegas do SOC Prime, que fornecem regras de detecção paga, mostraram um exemplo não útil dessa tradução: o campo deviceProduct no SIEM deve ser igual ao Sysmon e ao Microsoft Windows, o que é impossível.
Não quero culpar ninguém e cutucar um dedo - todo mundo é louco, tudo bem. No entanto, os consumidores de Inteligência contra ameaças precisam entender que ainda é necessário verificar novamente e refinar as regras obtidas de fontes abertas e fechadas.
Dica 4: verifique se há malware nos nomes de domínio e endereços IP, não apenas no servidor proxy e no firewall, mas também nos logs do servidor DNS, prestando atenção às tentativas de resolução bem-sucedidas e malsucedidas
Domínios maliciosos e endereços IP são um indicador ideal em termos de facilidade de detecção e quantidade de dor que você oferece a um invasor. Mas com eles tudo é simples apenas à primeira vista. No mínimo, você pode se perguntar de onde obter o log do domínio.
Se você se restringir a verificar apenas os logs do servidor proxy, poderá perder o malware que tenta acessar a rede diretamente ou solicitar um nome de domínio inexistente gerado pela DGA, sem mencionar os túneis DNS - tudo isso não estará nos logs de proxy corporativos.
Dica número 5. "Você não pode bloquear o monitor" - coloque uma vírgula somente depois de saber que tipo de indicador é e perceber as possíveis conseqüências do bloqueio
Cada segurança praticante enfrentou uma pergunta difícil: bloquear a ameaça ou monitorar e, se houver algum positivo, iniciar uma investigação? Alguns regulamentos e instruções gravam diretamente o bloco e, às vezes, essa ação é incorreta.
Se o indicador for o nome de domínio usado pelo agrupamento APT,
não o bloqueie , mas inicie o monitoramento. As táticas modernas de ataques direcionados implicam a existência de um canal de comunicação de backup encoberto adicional, que só pode ser identificado durante uma investigação detalhada. O bloqueio automático, neste caso, impedirá a busca por esse canal, e os camaradas do outro lado da barricada entenderão rapidamente o que você aprendeu sobre as atividades deles.
Por outro lado, se o indicador for um domínio criptografador, ele já
deverá estar bloqueado . Mas não se esqueça de monitorar tentativas malsucedidas de acessar domínios bloqueados - vários endereços de servidores de gerenciamento podem ser incorporados à configuração do criptografador. Alguns deles podem estar ausentes nos feeds e, portanto, não serão bloqueados. Mais cedo ou mais tarde, o malware entrará em contato com eles para obter uma chave que o host criptografará instantaneamente. Somente uma análise reversa da amostra pode garantir que você bloqueou todos os endereços do servidor de gerenciamento.
Dica número 6. Verifique todos os indicadores recebidos quanto à relevância antes de configurá-los para monitoramento ou bloqueio.
Lembre-se de que as informações sobre ameaças são criadas por pessoas que tendem a cometer erros ou algoritmos de aprendizado de máquina, que são ainda mais afetados por isso. Já testemunhamos como vários fornecedores de relatórios pagos sobre as atividades de grupos do APT acidentalmente adicionam amostras bastante legítimas às listas de MD5s maliciosos. Mesmo que os relatórios de ameaças pagas contenham indicadores de baixa qualidade, o que podemos dizer sobre indicadores obtidos por meio da inteligência em fontes abertas. Os analistas de TI nem sempre checam os indicadores que eles criam para falsos positivos, como resultado de tal verificação recair sobre os ombros do consumidor.
Por exemplo, se você recebeu o endereço IP da próxima modificação Zeus ou Dimnie, antes de usá-lo em sistemas de detecção,
verifique se ele faz parte da hospedagem ou serviço que indica seu IP . Caso contrário, será desagradável analisar um grande número de falsos positivos quando os usuários de um site hospedado nesta hospedagem acessarem sites completamente inofensivos. Uma verificação semelhante pode ser feita facilmente com:
- Serviços de categorização que informarão sobre a natureza das atividades do site. Por exemplo, o ipinfo.io grava diretamente o tipo: "hosting".
- IP reverso de serviços, que informa quantos domínios estão registrados neste endereço IP. Se houver muitos deles, é altamente provável que você esteja hospedando sites.
Assim, por exemplo, o resultado da verificação do indicador parece ser um indicador do grupo Cobalt APT (de acordo com o relatório de um fornecedor de TI respeitado):
Nós especialistas em resposta entendemos que os senhores da Cobalt devem ter usado esse endereço IP. No entanto, não há benefício com esse indicador - é irrelevante porque fornece muitos falsos positivos.
Dica número 7. Automatize todos os processos com informações sobre ameaças, tanto quanto possível. Comece com um simples - automatize totalmente a verificação de falsos positivos na lista de paradas, com a configuração adicional de indicadores sem riscos para monitoramento no SIEM
Para evitar um grande número de falsos positivos relacionados à inteligência e obtidos de fontes abertas, é possível uma pesquisa preliminar desses indicadores nas listas de paradas (listas de aviso). Essas listas podem ser formadas com base na classificação Alexa (top-1000), endereços de sub-redes internas, domínios de grandes provedores de serviços como Google, Amazon AWS, MS Azure e outros serviços de hospedagem. Também extremamente eficaz será uma solução que altera dinamicamente as listas de paradas que consistem nos principais domínios / endereços IP visitados pelos funcionários da empresa na última semana ou mês.
O desenvolvimento dessas listas e um sistema de verificação pode ser difícil para o SOC médio, por isso faz sentido pensar em implementar as chamadas plataformas de Inteligência contra Ameaças. Há cerca de meio ano, o Anti-malware.ru tinha uma boa
visão geral das soluções pagas e gratuitas dessa classe.
Dica número 8. Analise a empresa inteira em busca de indicadores de host, não apenas hosts conectados ao SIEM
Como, regra geral, nem todos os hosts corporativos estão conectados ao SIEM, não é possível verificar se há um arquivo mal-intencionado com um nome ou caminho específico, usando apenas a funcionalidade SIEM padrão. Você pode sair dessa situação das seguintes maneiras:
- Use scanners de IoC como o Loki . Você pode executá-lo em todos os hosts da empresa através do mesmo SCCM e redirecionar a saída para uma pasta de rede pública.
- Use scanners de vulnerabilidade. Alguns deles têm modos de conformidade nos quais você pode verificar um arquivo específico em um caminho específico.
- Escreva um script do PowerShell e execute-o no WinRM. Se você mesmo escrever preguiça, poderá usar um dos muitos scripts, por exemplo, este.
Como eu disse no começo, este artigo não implica informações abrangentes sobre como trabalhar corretamente com a Inteligência de Ameaças. No entanto, em nossa experiência, seguir essas regras simples permitirá que os iniciantes não entrem no rake e iniciem imediatamente um trabalho eficaz com vários indicadores de comprometimento.