Nós do JSOC CERT estamos investigando incidentes. Em geral, todas as 170 pessoas no JSOC estão investigando, mas os casos mais tecnologicamente desafiadores caem nas mãos de especialistas do CERT. Como, por exemplo, detectar vestígios de um malware se um invasor limpava? Como encontrar um "assistente" que excluiu documentos comerciais importantes de um servidor de arquivos no qual o log não está configurado corretamente? Bem, como sobremesa: como um invasor pode obter senhas de dezenas de contas de domínio não relacionadas sem penetrar na rede? Detalhes, como sempre, sob o corte.
Dias úteis JSOC CERT
Muitas vezes, temos que avaliar o comprometimento real da rede de clientes, para isso realizamos:
- análise retrospectiva de discos rígidos e imagens de memória,
- engenharia reversa de malware
- se necessário, implantação emergencial de monitoramento e varredura de hosts em busca de indicadores de comprometimento e traços de hackers.
Em nosso tempo livre, escrevemos resumos, técnicas e manuais detalhados - essencialmente instruções que ajudam a dimensionar até investigações complexas, como você pode agir de forma semi-automática.
Às vezes, durante a resposta ao incidente - bem no meio da extinção de um “incêndio” - você também precisa atuar como um “serviço de apoio psicológico”. Uma vez fomos convidados a ajudar a combater a infecção da sub-rede de uma grande organização. A rede foi atendida por dois contratados que, nessa situação, se desinteressadamente
se jogavam em um ventilador e estavam envolvidos em qualquer outra coisa, mas sem procurar um verme malicioso. Para reduzir o grau de histeria, tive que sentar todos na mesa
para pegar uma toalha e uma garrafa de bourbon e explicar claramente que agora não é hora de procurar os culpados. Eles determinaram o procedimento de distribuição, lançaram uma auditoria adicional e começaram a limpar sistematicamente a infecção juntos e em conjunto.
Durante a investigação, geralmente precisamos escolher imagens de disco e memória para encontrar malware ativo lá. Para tornar o processo previsível e objetivo, formalizamos e automatizamos vários métodos para análise retrospectiva de discos e tomamos como base o já clássico método
SANS - na versão original, ele é de alto nível, mas, se usado corretamente, permite a detecção de infecção ativa com uma precisão muito alta.
É claro que executar verificações completas requer tempo e profundo conhecimento especializado sobre os recursos dos vários componentes dos sistemas operacionais (e o software especializado precisa muito).
Como simplificar a verificação de um disco para infecção ativa? Compartilhamos o truque da vida - ele pode ser verificado dinamicamente (como na caixa de proteção), para isso:
- copie o disco rígido do host suspeito pouco a pouco;
- converta a imagem dd resultante para o formato VMDK usando este utilitário;
- execute a imagem VMDK no Virtual Box / VMware;
- e analise como um sistema vivo, focando no tráfego.
Mas sempre haverá incidentes nos quais instruções detalhadas não são escritas e as técnicas não são automatizadas.Caso 1. O contador não tem nada a ver com isso, ou como procuramos por malware
O cliente nos pediu para verificar se há malware no computador do contador: alguém fez várias ordens de pagamento para um endereço desconhecido. O contador alegou que não estava envolvido nisso e que o computador havia se comportado de maneira estranha antes: o mouse às vezes se movia literalmente pela tela - na verdade, fomos solicitados a verificar essas indicações. O problema foi que o cavalo de Tróia que visava o 1C fez suas ações sujas e limpou, e quase um mês se passou após a infecção - durante esse período, o diligente enikeyschik colocou um monte de software, esfregando o espaço em disco não alocado e, assim, minimizando a probabilidade de sucesso na investigação.
Nesses casos, apenas um analista experiente e meticuloso e um extenso banco de dados atualizado do Threat Intelligence podem ajudar. Portanto, durante a verificação da pasta de inicialização, a atenção foi atraída por uma marca suspeita, indicando um suposto utilitário de atualização de antivírus:
Infelizmente, a carcaça do cavalo de Tróia do disco não pôde ser restaurada, mas os fatos de iniciar o utilitário de administração remota da mesma pasta "ostentam" no cache do
Superfetch :
Comparando-os com a época do incidente, provamos que não era o contador culpado de roubar o dinheiro, mas um atacante externo.
Caso 2. Quem excluiu meus arquivos?
A maioria de nossas investigações e respostas a incidentes está de alguma forma relacionada à detecção de malware, ataques direcionados usando utilitários de vários módulos e histórias semelhantes em que há um invasor externo. No entanto, às vezes há investigações muito mais mundanas, mas não menos interessantes.
O cliente tinha o servidor de arquivos antigo mais comum, cujas pastas públicas eram acessíveis a vários departamentos. No servidor, havia muitos documentos comerciais muito importantes que alguém pegou e excluiu. Percebemos isso tarde - depois que o backup foi sobrecarregado. Eles começaram a procurar os culpados.
Se você já tentou pesquisar no Google como determinar qual usuário excluiu o arquivo, provavelmente encontrou dicas que vêm nos logs do Windows, se você configurá-las corretamente com antecedência (a propósito, já damos
algumas dicas sobre como configurar logs):
FonteMas, na realidade, poucas pessoas realizam auditorias no sistema de arquivos, brega porque há muitas operações de arquivos e os logs serão rapidamente desgastados, e é necessário um servidor separado para armazenar os logs ...
Decidimos dividir a tarefa em duas: primeiro, determine QUANDO os arquivos foram excluídos; segundo, - a OMS estava se conectando ao servidor no momento da exclusão. Se você tiver uma idéia dos recursos do NTFS, saberá que, na maioria das implementações deste sistema de arquivos, quando você exclui um arquivo, o espaço ocupado por ele é marcado como livre e seus carimbos de hora não são alterados. Portanto, à primeira vista, o tempo de exclusão não pode ser definido.
No entanto, o sistema de arquivos contém não apenas arquivos, mas também pastas. Além disso, as pastas têm um atributo especial $ INDEX_ROOT, que descreve o conteúdo da pasta como uma árvore B. Naturalmente, excluir um arquivo altera o atributo $ INDEX_ROOT da pasta e, portanto, altera seus carimbos de data e hora, em particular, na estrutura de $ STD_INFO. Assim, é possível determinar o tempo aproximado para excluir um grande número de arquivos e pastas por anomalia na
MFT (tabela principal de arquivos) :
Depois de descobrir quando os arquivos foram aproximadamente excluídos, você pode tentar descobrir quem estava trabalhando no norte naquele momento para restringir o círculo de suspeitos. Os seguintes métodos vêm à mente:
- Pelos logs do próprio servidor - por eventos com o EventID 4624/4625, é visível quando o usuário é conectado e desconectado;
- pelos logs do controlador de domínio - o EventID 4768 permite determinar que um usuário específico solicitou acesso ao servidor;
- pelo tráfego - netflow / logs internos do roteador - você pode descobrir quem se comunicou ativamente pela rede com este servidor via smb.
No nosso caso, esses dados não estavam mais lá: havia passado muito tempo, os logs foram rotacionados. Nesse caso, existe outro método não muito confiável, mas ainda assim um método, ou melhor, a chave do Registro -
Shellbags . Ele armazena informações, em particular, sobre que tipo de pasta a última vez que o usuário a visitou: tabela, lista, ícones grandes, ícones pequenos, conteúdo, etc. E a mesma chave contém registros de data e hora, que podem ser interpretados com alta confiança como o horário da última visita à pasta.
Foi encontrado um método, a única coisa que restava era coletar os registros dos hosts necessários e analisá-los. Para fazer isso, você precisa:
- determinar por grupo de domínio que teve acesso à pasta (no nosso caso, havia cerca de 300 usuários);
- coletar registros de todos os hosts nos quais esses usuários trabalharam (você não pode fazer isso, é necessário um utilitário especial para trabalhar diretamente com a unidade, por exemplo, https://github.com/jschicht/RawCopy );
- "Alimente" todos os registros na Autópsia e use o plug-in Shellbags;
- Lucro!
Especificamente, neste incidente, o tempo para excluir arquivos coincidiu com o tempo em que um usuário visitou a raiz da pasta excluída, o que nos permitiu restringir o círculo de suspeitos de 300 para 1.
O que aconteceu depois com esse funcionário - a história é silenciosa. Sabemos apenas que a menina confessou que o fez por acidente e continua trabalhando na empresa.
Caso 3. Senha mestre: "roubar" em alguns segundos (e ainda mais rápido)
Um invasor entrou na rede de um cliente que nos pediu ajuda através de uma VPN e foi imediatamente detectado. O que não é surpreendente, porque logo após entrar, ele começou a varrer a sub-rede com um scanner de vulnerabilidades - o chanipot piscou como uma árvore de Natal.
Depois que a conta foi bloqueada, a equipe de segurança do cliente começou a analisar os logs da VPN e viu que o invasor havia usado mais de 20 contas de domínio diferentes para a penetração (com a maioria das quais ele efetuou login com êxito, mas para algumas a autenticação não teve êxito). E surgiu a pergunta lógica: como ele descobriu as senhas dessas contas? Nossos funcionários do JSOC CERT foram convidados a procurar a resposta.
Em um dos
artigos anteriores, já dissemos que nas investigações hipóteses devem ser formadas e verificadas à medida que sua probabilidade diminui. Foi o que fizemos desta vez, começando a descrever vetores típicos de roubo de conta:
Verificamos várias versões, mas em nenhum lugar havia sequer uma sugestão de ataque. Não que a investigação estivesse em um impasse, mas a voz interior e o senso comum sugeriam que algo estava errado - você precisa dar um passo para trás e olhar a foto em geral.
De fato, à primeira vista, todas essas contas não estão de forma alguma conectadas. Seus proprietários são de diferentes departamentos geograficamente separados. Geralmente eles usam um conjunto não sobreposto de serviços da empresa. Até o nível de conhecimento em TI é diferente. Sim, um passo atrás não foi suficiente - era preciso mais um.
Nesse momento, conseguimos coletar um grande número de logs de diferentes sistemas da empresa e identificar os rastreamentos deixados pelo invasor. Eles começaram a analisar onde aparecia (lembro-me: ele examinou ativamente a rede interna da empresa). Percebemos que, no contexto de um ruído de rede uniformemente distribuído por explorações voadoras, há um número anormalmente grande de solicitações ao serviço de recuperação de senha. Um serviço acessível a partir da Internet. Hmm ...
Se você estiver monitorando eventos de segurança, provavelmente saberá que analisar as tentativas de atacar um servidor acessível externamente geralmente não faz sentido devido ao ruído da Internet: distinguir ataques realmente graves de inúmeras tentativas de script-kiddie geralmente não é fácil. Mas nem sempre.
Depois de passar algum tempo nos logs de serviço da web, conseguimos destacar os seguintes ataques no serviço:
- Digitalize com Acunetix
- Verificação do SQLmap
- um grande número de solicitações para uma página.
O terceiro ataque, à primeira vista, é semelhante a logins brutais de usuários. Mas não é assim, porque o serviço é protegido disso, pelo menos pelo fato de que as senhas são armazenadas em uma forma de hash com salt - ou não? Era necessário verificar rapidamente.
A figura abaixo mostra um esquema típico do serviço de redefinição de senha:
É interessante que as senhas nem sempre sejam armazenadas de forma segura - há um momento em que elas são de domínio público - imediatamente após o aplicativo ser aberto e antes de sua execução! Um grande número de consultas em uma página resultou não em força bruta e não em varredura, mas em consultas de alta frequência com injeção de SQL, cujo objetivo era extrair senhas no momento da alteração.
Portanto, depois de modelar o ataque ao serviço, comparar as informações dos logs do servidor web, dos logs de alteração de senha e de vários dispositivos de rede, ainda encontramos o ponto de penetração do invasor na empresa.
Então, colegas, mergulhem nos dados brutos e que a força esteja com você!
