Get best of the week

Investigação de incidentes de segurança da informação em estado selvagem: fontes inesperadas de informação

imagem

Muito foi escrito sobre a investigação de incidentes com computadores, ou Digital Forensics, existem muitas ferramentas de hardware e software prontas, os principais artefatos de sistemas operacionais são bem conhecidos e descritos em manuais, livros e artigos. Parece que é difícil - leia o manual e encontre o necessário. Mas há casos tecnicamente difíceis em que a análise desses artefatos muito conhecidos não fornece informações suficientes para restaurar a cronologia dos eventos. Como estar nesta situação? Nós o analisamos com exemplos reais de nossas investigações.

Por que existe uma falta geral de artefatos básicos? Podem existir várias razões:

  1. A infraestrutura não está preparada adequadamente para monitoramento e resposta completos a eventos ( escrevemos sobre isso aqui )
  2. , ( Digital Forensic)
  3. , ( – , MFT-).

Portanto, se a infraestrutura é grande e variada, o incidente se desenvolve há muito tempo e o atacante é um "kalach fragmentado", são necessárias fontes adicionais de informação para divulgar todas as suas ações e restaurar a cronologia dos eventos.

Dependendo da situação, sistemas SIEM, análise de fluxos de rede Netflow ou tráfego bruto (embora na realidade em 90% dos casos isso não seja possível), bem como artefatos incomuns que se relacionam a qualquer software de terceiros, por coincidência, podem ser úteis. na infraestrutura do cliente.

É no último tipo de artefato que vamos parar.

Ivanti Endpoint Manager (anteriormente LANDESK Management Suite). Sistema de gerenciamento de ativos de TI

www.ivanti.ru/company/history/landesk

Conectando-se ao monitoramento de um de nossos novos clientes, detectamos em sua infraestrutura a limpeza dos logs de eventos em um dos servidores, enquanto não havia outras manifestações de atividades maliciosas no sistema SIEM. Durante a análise, verificou-se que o servidor estava comprometido e o invasor usou equipamento especial para passar despercebido. Consistia no seguinte:

  1. Eventos de log de segurança foram redirecionados para um arquivo temporário separado,
  2. um invasor executou as ações necessárias,
  3. os eventos são redirecionados de volta ao log de segurança,
  4. arquivo temporário foi excluído.
  5. Lucro!

Como resultado, apesar do diário de segurança ter sido configurado adequadamente, ele não continha nenhum evento relacionado à atividade maliciosa, enquanto parecia intocado.

Após uma breve análise, descobrimos que o invasor "vive" na infraestrutura há cerca de 2 a 3 anos, o que possibilitou comprometer todos os principais servidores. Nesses casos, o valor de qualquer fonte adicional de informação aumenta, pois alguns artefatos básicos são desgastados ou pouco informativos e não permitem uma imagem completa do incidente.

Em busca de fontes adicionais de informação, realizamos um inventário oral de serviços e sistemas usados ​​na infraestrutura e descobrimos que, juntamente com a implementação de nosso monitoramento, o cliente começou a implantar um sistema de gerenciamento de ativos de TI
Ivanti Endpoint Manager.

Como o sistema ainda estava instável (os eventos dos agentes não foram enviados parcialmente
para o servidor), não conseguimos visualizar centralmente os eventos dos hosts no servidor. No entanto, tendo decidido procurar artefatos armazenados pelo Ivanti Endpoint diretamente no host, descobrimos que este software armazena informações sobre lançamentos de processos localmente no seguinte ramo de registro:

HKLM \ SOFTWARE \ Wow6432Node] \ LANDesk \ ManagementSuite \ WinClient \ SoftwareMonitoring \ MonitorLog \ < O caminho para o arquivo executável>

As seguintes informações são armazenadas nas chaves correspondentes:

  • primeira hora de início (no formato FILETIME)
  • último tempo de execução (no formato FILETIME)
  • número de partidas
  • usuário com direitos dos quais o arquivo executável foi iniciado


Artefatos de inicialização do processo do Ivanti Endpoint

Graças a essas informações, conseguimos determinar o tempo da aparência do invasor em alguns sistemas que desconhecíamos antes. Além disso, parte de seu kit de ferramentas foi divulgada com base apenas no nome dos arquivos executáveis.

Citrix NetScaler Sistema para fornecer acesso a recursos e aplicativos corporativos

www.citrix.com/pt-br/products/citrix-adc


Fluxo de trabalho do Citrix NetScaler

Outra investigação interessante. Um invasor entrou na infraestrutura da empresa por meio de uma VPN. Ele trabalhou no fuso horário UTC +8. Após a autenticação, ele se comportou de forma bastante agressiva (sub-redes internas ativamente verificadas usando a máscara / 24 e / 16), como resultado disso, de fato, foi percebido.

A VPN foi configurada no sistema de aplicativos e recursos corporativos Citrix NetScaler. Depois de estudar seus logs, conseguimos estabelecer o horário da primeira “visita” (leia a data do comprometimento), as contas dos funcionários usadas pelo invasor (a propósito, mais de 5 contas foram comprometidas) e os endereços IP dos servidores proxy nos quais ele trabalhava.

A investigação em si foi concluída com êxito: conseguimos estabelecer uma fonte de comprometimento - o sistema interno de redefinição de credenciais acessíveis pela Internet estava sujeito a injeção de SQL.

Mas agora quero observar outra coisa: depois de passar a autenticação VPN no Citrix NetScaler, todas as solicitações de usuário HTTP foram registradas com êxito. O invasor provavelmente não sabia disso ou confundiu suas interfaces de rede e enviou suas próprias consultas aos mecanismos de pesquisa através da rede corporativa do cliente. Isso nos permitiu obter informações sobre os sistemas de interesse do invasor, suas competências e as ferramentas utilizadas.


Arquivo de log do Citrix NetScaler


Informações que um invasor procurava através do Citrix NetScaler


Informações que um invasor procurava através do Citrix NetScaler

Secret Net Studio. Sistema para proteger informações de acesso não autorizado

www.securitycode.ru/products/secret_net Em

um belo dia, um ticket com um incidente de autenticação suspeito caiu em nossa primeira linha, sob a conta de um funcionário de TI da empresa no servidor de administração à noite (o próprio funcionário estava de férias na época, ele tinha uma VPN não tinha). Arquitetonicamente, o servidor de administração estava localizado em um segmento de rede separado, juntamente com vários outros servidores principais da empresa (incluindo o servidor Secret Net), enquanto o SIEM apenas recebia eventos do próprio servidor de administração (infelizmente, os clientes nem sempre concordam em conectar todas as fontes em potencial )

A primeira linha, processando o ticket e coletando informações sobre o que aconteceu após a autenticação, encontra vários processos suspeitos (caminhos não padrão, nomes de arquivos binários em uma letra) e o mstsc.exe, indicando uma possível sessão RDP.

Percebendo que este era um compromisso potencial, solicitamos imagens de todos os servidores
e começou sua análise. Abrindo a primeira imagem (servidor Secret Net), recebemos uma “grande surpresa” de presente: os logs do sistema, segurança e aplicativos foram excluídos e removidos para que até as tentativas de recuperação não tivessem êxito. Só foi possível comparar se as entradas nos logs do TerminalServices do servidor SecretS coincidiram com o lançamento do mstsc.exe no servidor de administração, o que significa que o invasor estava definitivamente na Secret Net. A análise dos servidores restantes também falhou.

Como resultado, nos encontramos em uma situação em que se sabe com certeza que o invasor está lá (ele definitivamente fez alguma coisa e a iniciou), mas não temos logs de host, porque os rastreamentos são excluídos
e não há logs de rede, porque todos os servidores estão na mesma sub-rede.

Uma solução foi encontrada mesmo nessa situação. O sistema Secret Net é muito versátil e consiste em muitos componentes, tanto no nível do kernel quanto no nível do usuário. Depois de analisar cada arquivo de log gravado e salvo por vários componentes da Secret Net, encontramos vários excelentes artefatos deixados pelo controle de arquivo. Quando reunimos tudo, obtivemos informações sobre as ações do atacante (ele realmente estava em todos os servidores desta sub-rede) e sobre suas ferramentas.

A propósito, as informações recebidas ajudaram a eliminar completamente a presença de um invasor na infraestrutura.


Esquema de um invasor que trabalha através do arquivo de controle de arquivo do servidor Secret Net Studio




KVRT. Ferramenta antivírus gratuita

www.kaspersky.ru/downloads/thank-you/free-virus-removal-tool

Fomos contatados para obter ajuda na investigação de um incidente relacionado à atividade maliciosa de saída (atividade de botnet e mineradora) nos endereços públicos da empresa. Após receber as imagens e os logs do sistema, iniciamos a análise e encontramos alguns artefatos indicando um comprometimento do serviço público da Web da organização e dos arquivos maliciosos restantes. Infelizmente, isso não foi suficiente para responder a todas as perguntas feitas pelo cliente: entre outras coisas, não encontramos vestígios de arquivo do mineiro, embora tenha demorado um pouco entre a correção de atividades maliciosas e nossa investigação.

Voltando mais uma vez aos artefatos e logs, chamamos a atenção para os traços de vários scanners antivírus gratuitos. Ficou claro que os arquivos que estavam faltando eram criptografados e colocados em quarentena e os carimbos de data e hora do sistema de arquivos foram apagados com segurança.

Entre os scanners utilizados estava o KVRT, que detectou alguns arquivos maliciosos e os colocou em quarentena. O local padrão dos arquivos de quarentena é C: \ KVRT_Data \ Quarantine, e descriptografá-los é muito fácil: um XOR simples com uma chave conhecida é e2 45 48 ec 69 0e 5c ac.


Descriptografada quarentena do KVRT

Como se viu depois, o administrador de TI ainda conseguiu verificar o sistema com antivírus gratuitos antes da nossa chegada, apesar da recomendação de não tocar em nada.
Como resultado, os arquivos em quarentena ajudaram a fechar lacunas na cronologia dos eventos e a responder a todas as perguntas.


Cada investigação é sempre algo incomum, único e versátil. Sim, existem artefatos conhecidos dos sistemas operacionais, mas antes do início da investigação, é difícil prever a integridade das informações que podem ser obtidas após a análise. Portanto, antes de uma investigação técnica do incidente, recomendamos que você faça um inventário do software e dos sistemas e não tenha preguiça de estudá-los como uma possível fonte na investigação.

More articles:


All Articles