IBo nefig: as melhores exposições de cibersegurança de 2020 de acordo com JSOC

A primeira metade do ano está chegando ao fim e decidimos relembrar os casos mais interessantes da vida do JSOC que encontramos este ano. Uma reunião com um cibercriminoso "velho amigo" em um novo cliente, um script malicioso no Agendador de Tarefas e o enigma da curva de configuração do balanceador - lemos e investigamos o problema.





Filmado da série South Park

Nós o reconhecemos por sua caligrafia

Durante a existência do JSOC, fomos confrontados com diferentes infraestruturas de TI e vários desejos dos clientes para monitorar a cobertura de seu cenário de TI. Muitas vezes acontece, por exemplo, que um cliente deseja monitorar apenas os servidores, privando-se da oportunidade de ver o que está acontecendo no segmento monitorado. Essa abordagem pode resultar em uma detecção de ataque tardia, quando a maior parte da infraestrutura já está comprometida. E se nossos clientes existentes não têm tais situações, então, em projetos-piloto, essa é uma história comum.



Portanto, durante um dos pilotos, o cliente estava em processo de reconstrução de seu próprio cenário de TI e queria ver como o SOC se encaixaria em sua nova infraestrutura e processos. Devido a várias circunstâncias além do nosso controle, não tínhamos uma única fonte de rede conectada, quekapets o quanto nos limitou na detecção de vários incidentes. Apenas um controlador de domínio, alguns servidores Windows, um servidor de e-mail e um antivírus estavam conectados. O piloto passou com bastante calma e foi padrão para nós : vários malwares foram encontrados na infraestrutura, uso de TOR e RATs proibidos. Mas um belo dia, um grande número de nossas regras começou a funcionar, entre elas estavam as regras da categoria Threat Hunting, que automatizam o processo de identificação de rastros de um invasor. O analista responsável logo percebeu que o caso cheirava a querosene e até percebeu com quem estava lidando.



O que aconteceu? A primeira coisa que vimos foi adicionar novas contas ao grupo Admins. Do Domínio. Mas mais uma regra funcionou, ou seja, o nome suspeito das contas, que já encontramos. Um velho conhecido nosso, um invasor, durante os ataques, cria duas contas que são escritas em seu script: esses dois nomes "vagam" de uma vítima para outra - uma pequena mudança só pode ser causada pelas regras de nomeação de contas da organização atacada. Nós o encontramos muitas vezes enquanto investigávamos incidentes. Ele ataca organizações de todos os tamanhos e setores com o mesmo método e, normalmente, acaba criptografando os principais servidores da empresa.



Infelizmente, a primeira máquina comprometida estava fora do escopo das fontes conectadas, portanto, o momento de iniciar o script em si não pôde ser registrado. Após a criação das contas, registramos uma mudança de regra no firewall local que permitia o uso de uma ferramenta de administração remota específica, e então foi criado o serviço do agente dessa mesma ferramenta. Já agora, o antivírus que o cliente utiliza não reconhece esta ferramenta, por isso controlamo-la criando o serviço correspondente e iniciando o processo.







A cereja do bolo foi a distribuição de um utilitário de criptografia legal para hosts comprometidos. Ele não teve tempo de enviá-lo para todos os hosts. O invasor foi "expulso" da infraestrutura 23 minutos após o primeiro disparo deste incidente.



É claro que o cliente e eu queríamos ter uma visão completa do incidente e encontrar o ponto de entrada do invasor. Com base em nossa experiência, solicitamos logs de equipamentos de rede, mas, infelizmente, o nível de login não nos permitiu tirar quaisquer conclusões. No entanto, depois de receber a configuração do equipamento de rede de borda dos administradores, vimos o seguinte:



ip nat dentro da fonte estática tcp "endereço cinza" 22 "endereço branco" 9922

ip nat dentro da fonte estática tcp "endereço cinza" 3389 "endereço branco" 33899



Do qual se concluiu que, muito provavelmente, um dos servidores onde tal NAT foi configurado se tornou o ponto de entrada. Analisamos os logs desses servidores e vimos a autenticação bem-sucedida na conta de administrador, iniciando o Mimikatz e, em seguida, um script que criava administradores de domínio. Por meio desse incidente, o cliente realizou uma auditoria completa das regras de firewall, senhas e políticas de segurança e identificou várias outras falhas em sua infraestrutura. E também obtive uma compreensão mais sistemática de por que o SOC é necessário em sua organização.

Roteadores remotos e domésticos - o paraíso dos hackers

Obviamente, nas condições de mudança das empresas para o controle remoto, ficou muito mais difícil monitorar eventos em dispositivos finais. Existem dois motivos principais:

1. um grande número de funcionários usa dispositivos pessoais para trabalhar;
2. VPN , .

Também é um fato óbvio que até mesmo invasores experientes se interessaram por redes domésticas, já que agora é o ponto ideal de penetração no perímetro corporativo.



Um de nossos clientes tinha 90% dos funcionários mudados para o modo de trabalho remoto e todos tinham laptops de domínio - portanto, poderíamos continuar monitorando os dispositivos finais - claro, levando em consideração o ponto 2 acima. E foi esse ponto que jogou contra nós.



Um dos usuários durante o auto-isolamento não se conectou à VPN por quase um dia inteiro. No final do dia, ele ainda precisava de acesso aos recursos corporativos. Ele usou uma VPN, pegamos os logs de sua máquina de trabalho e vimos algo estranho. Uma tarefa suspeita foi criada no Agendador de tarefas: ele inicia um determinado arquivo todas as quartas-feiras às 17:00. Eles começaram a entender.







Os rastreamentos levaram a dois arquivos doc: um deles criou a tarefa, o segundo era o arquivo executável da tarefa. O usuário os baixou do Google Drive.



Nesta fase da nossa pesquisa, o serviço de segurança do cliente já estava ligado e iniciou uma investigação interna. Acontece que o usuário recebeu uma carta em seu e-mail pessoal, que continha um link para o Google Drive, de onde os documentos foram baixados. Gradualmente, chegamos ao roteador do usuário - é claro, o login / senha dele era admin \ admin (como se fosse o contrário?). Mas o mais interessante foi constatado nas configurações do servidor DNS do roteador: ali estava indicado o endereço IP de um dos países europeus. Colocamos esse endereço no VirusTotal - a maioria das fontes iluminada em vermelho. Após o término da investigação, o cliente nos enviou dois arquivos para pesquisa, e vimos que o arquivo lançado pela tarefa começou a "percorrer" vários diretórios e baixar dados deles.



A cronologia do incidente foi a seguinte: o invasor obteve acesso ao roteador do usuário, alterou as configurações nele, especificando seu próprio servidor como servidor DNS. Por algum tempo observei minha "vítima" e enviei uma carta para o correio pessoal do usuário. Nesta etapa, nós o encontramos, impedindo-nos de nos aprofundarmos na infraestrutura corporativa.

Eles quebram o deles também

No estágio inicial de trabalho com um SOC terceirizado, sempre recomendamos conectar as fontes de eventos em etapas, para que o cliente por sua vez depure os processos, defina claramente as áreas de responsabilidade e, em geral, se acostume com este formato. Então, em um de nossos novos clientes, primeiro conectamos fontes básicas, como controladores de domínio, firewalls, proxies, várias ferramentas de segurança da informação, e-mail, servidores DNS e DHCP e vários outros servidores diferentes. Também nos oferecemos para conectar as máquinas dos administradores da matriz ao nível dos logs locais, mas o cliente disse que até agora não é necessário e confia nos seus administradores. Aqui, de fato, nossa história começa.



Um dia, os eventos pararam de vir até nós. Aprendemos com o cliente que, supostamente, devido a um ataque DDoS em grande escala, seu data center "caiu" e agora ele está envolvido na recuperação. Isso imediatamente levantou muitas questões - afinal, o sistema de proteção DDoS estava conectado a nós.



A analista imediatamente começou a vasculhar seus registros, mas não encontrou nada suspeito - tudo estava no modo normal. Em seguida, olhei os logs da rede e chamei a atenção para o estranho trabalho do balanceador, que distribuía a carga entre dois servidores que processam o tráfego de entrada. O balanceador de carga não distribuiu a carga, mas, ao contrário, direcionou-a para apenas um servidor até que fosse "engasgada" e só então redirecionou o fluxo para o segundo nó. Mas é muito mais interessante que assim que os dois servidores caíram, esse tráfego foi mais longe e "colocou" tudo no geral. Enquanto o trabalho de restauração estava em andamento, o cliente descobriu quem havia errado. Este, ao que parece, é o fim do incidente: não tem nada a ver com segurança da informação e está simplesmente associado a mãos tortas.erro do administrador. Mas o cliente decidiu investigar até o fim. Depois de verificar os AWPs dos administradores, ele descobriu que todos os logs do sistema operacional haviam sido limpos para o mesmo aspirante a artesão e então nos pediu para verificarmos suas ações na semana passada.



Curiosamente, esse administrador foi o objeto de nossas investigações algumas semanas antes do incidente. Ele acessou da rede local para um host externo na porta 22. Então, este incidente foi marcado como legítimo, porque os administradores não estão proibidos de usar recursos externos para automatizar seu próprio trabalho ou testar novas configurações de equipamento. Talvez essa conexão entre a queda do data center e a chamada para um host externo nunca tivesse sido percebida, mas houve outro incidente: chamadas de um dos servidores do segmento de teste para o mesmo host na Internet que o administrador havia contatado anteriormente - esse incidente também foi anotado pelo cliente como legítimo. Depois de observar a atividade do administrador, vimos solicitações constantes para esse servidor do segmento de teste e pedimos ao cliente para testá-lo.



E aqui está o desenlace - um servidor web foi implantado naquele servidor, que implementa funcionalidade parcial do site principal do cliente. Descobriu-se que o administrador estava planejando redirecionar parte do tráfego de entrada para seu site falso, a fim de coletar dados do usuário para seus próprios fins.

Resultado

Apesar de já ser 2020, muitas organizações ainda não aderem às verdades comuns da segurança da informação, e a irresponsabilidade de sua própria equipe pode levar a consequências desastrosas.



A esse respeito, aqui estão algumas dicas:

1. Nunca exponha RDP e SSH para o exterior, mesmo que você os esconda atrás de outras portas - isso não ajuda.
2. Ajuste o nível de registro mais alto possível para acelerar a detecção de intrusos.
3. Threat Hunting . TTPs , . .
4. , . , , .

, Solar JSOC (artkild)