A caça a ameaças ou TH é uma pesquisa proativa de traços de hackers ou o funcionamento de malware que não são detectados pelos meios de proteção padrão. Hoje falaremos sobre como esse processo funciona, quais ferramentas podem ser usadas para procurar ameaças, o que lembrar ao formar e testar hipóteses.
O que é a caça às ameaças e por que é necessário
No processo de busca de ameaças, o analista não espera até que os sensores dos sistemas de proteção sejam acionados, mas procura propositadamente traços de comprometimento. Para fazer isso, ele desenvolve e verifica suposições sobre como os invasores poderiam ter penetrado na rede. Tais verificações devem ser consistentes e regulares.
A implementação correta do processo deve levar em consideração os princípios:
- Deve-se assumir que o sistema já foi comprometido. O objetivo principal é encontrar traços de penetração.
- Para pesquisar, você precisa de uma hipótese sobre como exatamente o sistema foi comprometido.
- A pesquisa deve ser realizada iterativamente, ou seja, após testar a próxima hipótese, o analista apresenta uma nova e continua a pesquisa.
Freqüentemente, as defesas automatizadas tradicionais perdem ataques direcionados sofisticados . O motivo é que esses ataques costumam se espalhar ao longo do tempo, portanto, as ferramentas de segurança não podem correlacionar as duas fases de um ataque. Ao mesmo tempo, os atacantes pensam cuidadosamente sobre os vetores de penetração e desenvolvem cenários para ações na infraestrutura. Isso permite que eles não realizem ações de desmascaramento e transmitam suas atividades como legítimas. Os invasores estão constantemente aprimorando seus conhecimentos, comprando ou desenvolvendo novas ferramentas.
Os problemas de identificação de ataques direcionados são especialmente relevantes para organizações que foram hackeadas anteriormente. De acordo com o relatórioNo FireEye M-Trends, 64% das organizações anteriormente comprometidas foram atacadas novamente. Acontece que mais da metade das empresas invadidas ainda estão em risco. Isso significa que é necessário aplicar medidas para a detecção precoce dos fatos do comprometimento - isso pode ser alcançado com a ajuda do TH.
A busca por ameaças ajuda os especialistas em segurança da informação a reduzir o tempo para detectar uma violação, além de atualizar o conhecimento sobre a infraestrutura protegida. O TH também é útil ao usar a inteligência de ameaças (TI) - especialmente quando os indicadores de TI são usados ao se fazer uma hipótese.
Como formar hipóteses para teste
Como ao realizar o TH, é assumido, a priori, que o invasor já penetrou na infraestrutura, a primeira coisa a fazer é localizar o local da pesquisa de vestígios de hackers. Isso pode ser determinado apresentando uma hipótese sobre como a penetração ocorreu e que confirmação disso pode ser encontrada na infraestrutura. Tendo formulado uma hipótese, o analista verifica a verdade de sua suposição. Se a hipótese não for confirmada, o especialista passa a desenvolver e testar uma nova. Se, como resultado do teste da hipótese, forem encontrados vestígios de hackers ou a presença de malware for estabelecida, uma investigação será iniciada.
Figura 2. Esquema de condução da caça às ameaças
A idéia de uma hipótese pode nascer da experiência pessoal do analista; no entanto, existem outras fontes para sua construção, por exemplo:
- threat intelligence (TI-). , : X, MD5- Y.
- , (TTPs). TTPs MITRE ATT&CK. : .
- . . , asset management . .
- , .
threat hunting
Após formular uma hipótese, é necessário identificar fontes de dados que possam conter informações para testá-las. Freqüentemente, essas fontes contêm muitos dados, entre os quais você precisa achar relevante. Assim, o processo TH se resume a pesquisar, filtrar e analisar uma enorme quantidade de dados sobre o que está acontecendo na infraestrutura. Considere as fontes nas quais as informações podem ser encontradas para testar a hipótese de pesquisa:
Figura 3. Classificação das fontes de informações para a realização de TH
A maior quantidade de informações relevantes está contida nos logs e no tráfego da rede. Os produtos das classes SIEM (gerenciamento de informações de segurança e eventos) e NTA (análise de tráfego de rede) ajudam a analisar as informações deles. Fontes externas (como feeds de TI) também devem ser incluídas no processo de análise.
Como funciona na prática
O principal objetivo do TH é detectar uma violação que não foi detectada pelas ferramentas de segurança automatizadas.
Por exemplo, considere testar duas hipóteses. Na prática, mostraremos como os sistemas de análise de tráfego e análise de logs se complementam no processo de teste de hipóteses.
Hipótese nº 1: um invasor entrou na rede através de uma estação de trabalho e tenta obter controle sobre outros nós na rede, usando a execução de comandos WMI para avançar.
Os invasores obtiveram as credenciais de um usuário root. Depois disso, eles tentam assumir o controle de outros nós na rede para chegar ao host com dados valiosos. Um dos métodos para iniciar programas em um sistema remoto é usar a tecnologia WMI ( Windows Management Instrumentation ). Ela é responsável pelo gerenciamento e monitoramento centralizados das várias partes da infraestrutura de computadores. No entanto, os criadores previram a possibilidade de aplicar essa abordagem aos componentes e recursos não apenas de um único host, mas também de um computador remoto. Para isso, foi implementada a transmissão de comandos e respostas através do protocolo DCERPC.
Portanto, para testar a hipótese, você precisa examinar as consultas do DCERPC. Vamos mostrar como isso pode ser feito usando a análise de tráfego e um sistema SIEM. Na fig. 4 mostra todas as interações de rede DCERPC filtradas. Por exemplo, escolhemos o intervalo de tempo de 06:58 a 12:58. Figura 4. Sessões filtradas do DCERPC . 4, vemos dois painéis. À esquerda, os nós que iniciaram as conexões DCERPC. À direita estão os nós aos quais os clientes se conectaram. Como você pode ver na figura, todos os clientes na rede acessam apenas o controlador de domínio. Esta é uma atividade legítima, pois os hosts unidos em um domínio do Active Directory usam o protocolo DCERPC para entrar em contato com um controlador de domínio para sincronização. Seria considerado suspeito no caso de tal comunicação entre os hosts do usuário.
Como nada suspeito foi identificado para o período selecionado, movendo-se ao longo da linha do tempo, selecionamos as próximas 4 horas. Agora é um intervalo de 12:59 a 16:46. Nele, notamos uma mudança estranha na lista de hosts de destino (veja a Fig. 5). Figura 5. Após alterar o intervalo de tempo, dois novos nós apareceram na lista de servidores.Na lista de hosts de destino, existem dois novos nós. Considere aquele sem nome DNS (10.125.4.16). Figura 6. Refinamento do filtro para descobrir quem se conectou a 10.125.4.16 Como você pode ver na fig. 6, o controlador de domínio 10.125.2.36 acessa (veja a Figura 4), o que significa que essa interação é legítima.
Em seguida, você precisa analisar quem se conectou ao segundo novo nó, na Fig. 5 é win-admin-01.ptlab.ru (10.125.3.10). A partir do nome do nó, segue-se que este é o computador do administrador. Depois que o filtro é refinado, apenas dois nós de origem da sessão permanecem. Figura 7. Refine o filtro para descobrir quem se conectou ao win-admin-01. Similar ao caso anterior, um dos iniciadores era um controlador de domínio. Essas sessões não são suspeitas, pois são comuns em um ambiente do Active Directory. No entanto, o segundo nó (w-user-01.ptlab.ru), a julgar pelo nome, é o computador do usuário - essas conexões são anomalias. Se você for para a guia Sessões com esse filtro, poderá fazer o download do tráfego e ver os detalhes no Wireshark. Figura 8. Fazendo download de sessões relevantes
No tráfego, você pode ver uma chamada para a interface IWbemServices, que indica o uso de uma conexão WMI. Figura 9. Chamando a interface IWbemServices (Wireshark) Além disso, as chamadas transmitidas são criptografadas, portanto os comandos específicos são desconhecidos. Figura 10. O tráfego DCERPC é criptografado, portanto, o comando transmitido não é visível (Wireshark) Para finalmente confirmar a hipótese de que essa comunicação é ilegítima, é necessário verificar os logs do host. Você pode acessar o host e ver os logs do sistema localmente, mas é mais conveniente usar um sistema SIEM. Na interface SIEM, introduzimos uma condição no filtro que deixava apenas os logs do nó de destino no momento do estabelecimento de uma conexão DCERPC e vimos a seguinte imagem:
Figura 11. Logs do sistema win-admin-01 no momento do estabelecimento de uma conexão DCERPC
Nos logs, vimos uma correspondência exata com a hora de início da primeira sessão (consulte a Fig. 9), o iniciador da conexão é o host w-user-01. Uma análise mais aprofundada dos logs mostra que eles se conectaram sob a conta PTLAB \ Admin e executaram o comando (consulte a Fig. 12) para criar o usuário john com a senha senha !!!: net user john password !!! / adicionar. Figura 12. Comando executado durante a conexão
Descobrimos que, no nó 10.125.3.10, alguém usando o WMI em nome da conta PTLAB \ Admin adicionou um novo usuário ao host win-admin-01.ptlab.ru. Ao realizar TH real, o próximo passo é descobrir se essa é uma atividade administrativa. Para fazer isso, é necessário entrar em contato com o proprietário da conta PTLAB \ Admin e descobrir se ele executou as ações descritas. Como o exemplo considerado é sintético, assumiremos que essa atividade é ilegítima. Além disso, ao realizar uma TN real, no caso de revelar o fato de uso ilegal da conta, você precisa criar um incidente e conduzir uma investigação detalhada.
Hipótese nº 2: um invasor penetrou na rede e está no estágio de exfiltração de dados, usando o tunelamento de tráfego para gerar dados.
Tráfego de encapsulamento - organizando um canal de forma que os pacotes de um protocolo de rede (possivelmente de forma modificada) sejam transmitidos dentro dos campos de outro protocolo de rede. Um exemplo comum de encapsulamento é a construção de pipes criptografados como SSH. Canais criptografados garantem a confidencialidade das informações transmitidas e são comuns nas redes corporativas modernas. No entanto, existem opções exóticas, como túneis ICMP ou DNS. Tais túneis são usados pelos criminosos cibernéticos para disfarçar sua atividade como legítima.
Vamos começar encontrando a maneira mais comum de encapsular o tráfego através do protocolo SSH. Para fazer isso, filtraremos todas as sessões usando o protocolo SSH: Figura 13. Pesquisando sessões DNS no tráfego
Na figura, você pode ver que não há tráfego SSH na infraestrutura, portanto, é necessário escolher o seguinte protocolo que pode ser usado para o tunelamento. Como o tráfego DNS sempre é permitido nas redes corporativas, consideraremos abaixo.
Se você filtrar o tráfego pelo DNS, poderá ver que um dos nós possui um número anormalmente grande de consultas DNS.
Figura 14. Widget com estatísticas de sessões de clientes DNS
Após filtrar as sessões por fonte de solicitações, aprendemos para onde essa quantidade anômala de tráfego é enviada e como é distribuída entre os nós de destino. Na fig. A Figura 15 mostra que parte do tráfego vai para o controlador de domínio, que atua como o servidor DNS local. No entanto, uma grande proporção de solicitações vai para um host desconhecido. Em uma rede corporativa criada no Active Directory, os computadores dos usuários para resolução de nomes DNS não devem usar um servidor DNS externo para ignorar o servidor corporativo. Se essa atividade for detectada, você precisará descobrir o que está sendo transmitido no tráfego e para onde todas essas solicitações são enviadas. Figura 15. Pesquisando tráfego para sessões SSH
Se você for para a guia "Sessões", poderá ver o que é transmitido nas solicitações ao servidor suspeito. O tempo entre solicitações é bastante curto e há muitas sessões. Esses parâmetros são incomuns para tráfego DNS legítimo.
Figura 16. Parâmetros de tráfego DNS
Após abrir qualquer placa de sessão, vemos uma descrição detalhada de solicitações e respostas. As respostas do servidor não contêm erros, mas os registros solicitados parecem muito suspeitos, pois geralmente os nós têm nomes DNS mais curtos e mais significativos. Figura 17. Solicitação de registro DNS suspeita A análise de tráfego mostrou que atividades suspeitas no envio de solicitações DNS estão ocorrendo no host win-admin-01. É hora de analisar os logs do nó da rede - a fonte desta atividade. Para fazer isso, vá para SIEM.
Precisamos encontrar os logs do sistema win-admin-01 e ver o que aconteceu por volta das 17:06. Você pode ver que um script suspeito do PowerShell estava sendo executado ao mesmo tempo. Figura 18. Execução do PowerShell ao mesmo tempo em que envia solicitações suspeitas Os logs registram qual script estava sendo executado. Figura 19. Corrigindo o nome do script em execução nos logs O nome do script executado admin_script.ps1 sugere legitimidade, mas os administradores geralmente atribuem o nome aos scripts para uma função específica, e aqui o nome é geral. Além disso, o script está localizado na pasta para arquivos temporários. É improvável que um script administrativo importante termine em uma pasta que possa ser esvaziada a qualquer momento.
Entre os eventos descobertos estava a criação de uma classe criptográfica incomum da biblioteca Logos.Utility. Essa biblioteca é rara e não é mais suportada pelo desenvolvedor, portanto, criar suas classes é incomum. Vamos tentar encontrar projetos que o usem. Figura 20. Criando uma classe criptográfica customizada Se você usar a pesquisa, poderá encontrar um utilitário que organize um túnel DNS e use essa classe usando o segundo link. Figura 21. Procurando informações sobre um script pelo nome da classe Para finalmente garantir que este seja o utilitário de que precisamos, vamos procurar sinais adicionais nos logs. Então a evidência veio à luz. O primeiro é executar o utilitário nslookup usando um script. Figura 22. Executando o utilitário nslookup pelo script
O utilitário nslookup.exr é usado durante o diagnóstico de rede e raramente é executado por usuários regulares. Iniciar é visível nos códigos-fonte do utilitário. Figura 23. Código para ativar o utilitário nslookup (GitHub) A segunda prova é uma sequência bastante exclusiva para gerar valores aleatórios. Figura 24. Gerando valores aleatórios pelo script Se você usar a pesquisa nos códigos-fonte, poderá ver esta mesma linha. Figura 25. Código para gerar um valor aleatório A hipótese do túnel foi confirmada, mas a essência das ações executadas permaneceu incerta. Durante a análise subsequente dos logs, notamos dois lançamentos de processos. Figura 26. Procure documentos do escritório para mais exfiltração
As linhas de inicialização dos processos encontrados indicam a pesquisa de documentos para download. Assim, a hipótese foi totalmente confirmada, os invasores realmente usaram o tunelamento de tráfego para baixar dados.
conclusões
Como mostram os últimos relatórios de pesquisa , o tempo médio que os invasores permanecem na infraestrutura permanece longo. Portanto, não espere por sinais de defesas automatizadas - aja de maneira proativa. Estude sua infraestrutura e métodos modernos de ataque e use as pesquisas realizadas pelas equipes de TI ( FireEye , Cisco , PT Expert Security Center ).
Não estou pedindo o abandono das proteções automatizadas. No entanto, não se deve presumir que a instalação e a configuração correta desse sistema sejam o ponto final. Este é apenas o primeiro passo necessário. Em seguida, você precisa monitorar o desenvolvimento e o funcionamento do ambiente de rede controlado, manter o dedo no pulso.
As dicas a seguir ajudarão você:
- . . , .
- . , .
- . , . . , TH , .
- Automatize tarefas de rotina para ter mais tempo para ser criativo e experimentar soluções criativas.
- Simplifique o processo de análise de grandes quantidades de dados. Para fazer isso, é útil usar ferramentas que ajudem o analista a ver o que está acontecendo na rede e nos nós da rede como uma única imagem. Essas ferramentas incluem uma plataforma para troca de indicadores de TI , um sistema de análise de tráfego e um sistema SIEM .
Postado por Anton Kutepov, PT Expert Security Center da Positive Technologies.
Toda a análise foi realizada no sistema de análise de tráfego PT Network Attack Discovery e no sistema de gerenciamento de eventos de segurança MaxPatrol SIEM.