A estação de trabalho do usuário é o ponto mais vulnerável da infraestrutura em termos de segurança da informação. Os usuários podem receber um e-mail parecendo de uma fonte segura, mas com um link para um site infectado. É possível que alguém baixe uma ferramenta útil de um lugar desconhecido. É fácil criar várias situações em que o malware pode se infiltrar nos recursos internos por meio dos usuários. Portanto, as estações de trabalho requerem atenção especial, e neste artigo, discutiremos de onde e quais eventos coletar para monitorar ataques.
Para identificar um ataque em seu estágio mais inicial, o Windows possui três fontes de eventos úteis: log de eventos de segurança, log de monitoramento do sistema e logs do PowerShell.
Log de eventos de segurança (Security Log)
Este é o principal local de armazenamento dos logs de segurança do sistema. Aqui são registrados eventos de login/logout dos usuários, acesso a objetos, alterações de políticas e outras atividades relacionadas à segurança. Naturalmente, isso depende da política correspondente estar configurada.
Exploração de usuários e grupos (eventos 4798 e 4799). O malware, no início do ataque, muitas vezes explora contas de usuários e grupos locais na estação de trabalho para encontrar credenciais para suas atividades ilícitas. Esses eventos podem ajudar a detectar o código malicioso antes que ele avance e, usando os dados coletados, se espalhe para outros sistemas.
Criação de contas locais e alterações em grupos locais (eventos 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 e 5377). Um ataque também pode começar, por exemplo, com a adição de um novo usuário ao grupo de administradores locais.
Tentativas de login com uma conta local (evento 4624). Usuários legítimos entram com uma conta de domínio, e uma identificação de login com uma conta local pode indicar o início de um ataque. O evento 4624 também inclui logins com contas de domínio, portanto, ao processar os eventos, deve-se filtrar aqueles em que o domínio difere do nome da estação de trabalho.
Tentativa de login com uma conta especificada (evento 4648). Isso acontece quando o processo é executado no modo "Executar como". Em condições normais de operação do sistema, isso não deveria ocorrer, portanto, esses eventos devem ser monitorados.
Bloqueio/desbloqueio da estação de trabalho (eventos 4800-4803). Podem ser considerados suspeitos quaisquer ações que ocorreram em uma estação de trabalho bloqueada.
Mudanças na configuração do firewall (eventos 4944-4958). É evidente que ao instalar um novo software, as configurações do firewall podem ser alteradas, o que pode causar falsos positivos. Em muitos casos, não há necessidade de monitorar tais mudanças, mas saber sobre elas certamente não é demais.
Conexão de dispositivos Plug’n’play (evento 6416 e apenas para Windows 10). É importante ficar atento a isso, caso usuários normalmente não conectem novos dispositivos à estação de trabalho, e de repente a conexão acontece.
O Windows inclui 9 categorias de auditoria e 50 subcategorias para ajustes finos. O conjunto mínimo de subcategorias que deve ser habilitado nas configurações é:
Logon/Logout
- Logon;
- Logout;
- Bloqueio de Conta;
- Outros Eventos de Logon/Logout.
Gerenciamento de Conta
- Gerenciamento de Conta de Usuário;
- Gerenciamento de Grupo de Segurança.
Mudanças de Política
- Mudança na Política de Auditoria;
- Mudança na Política de Autenticação;
- Mudança na Política de Autorização.
Monitor de Sistema (Sysmon)
Sysmon é uma ferramenta interna do Windows que registra eventos no log do sistema. Geralmente, requer instalação separada.
Esses mesmos eventos podem ser encontrados no log de segurança (ativando a política de auditoria necessária), mas o Sysmon oferece mais detalhes. Quais eventos podem ser coletados do Sysmon?
Criação de processo (ID do evento 1). O log do sistema de eventos de segurança também pode indicar quando algum *.exe foi iniciado e até mostrar seu nome e caminho de execução. Mas, ao contrário do Sysmon, não pode mostrar o hash do aplicativo. Um malware pode ser nomeado como um inofensivo notepad.exe, mas o hash revelará sua verdadeira natureza.
Conexões de rede (ID do evento 3). É evidente que há muitas conexões de rede e não é possível monitorar todas. Mas é importante considerar que o Sysmon, ao contrário do Security Log, consegue vincular a conexão de rede aos campos ProcessID e ProcessGUID, mostrando a porta e endereços IP o endereço de origem e destino.
Mudanças no registro do sistema (ID do evento 12-14). A maneira mais simples de adicionar-se à inicialização automática é fazer uma entrada no registro. O Security Log faz isso, mas o Sysmon mostra quem fez as alterações, quando, de onde, o ID do processo e o valor anterior da chave.
Criação de arquivo (ID do evento 11). O Sysmon, ao contrário do Security Log, mostrará não apenas a localização do arquivo, mas também seu nome. É claro que não é possível monitorar tudo, mas é possível auditar diretórios específicos.
E agora, o que não está nas políticas do Security Log, mas está no Sysmon:
Alteração da data de criação do arquivo (ID do evento 2). Algum malware pode alterar a data de criação do arquivo para escondê-lo dos relatórios de arquivos recém-criados.
Carregamento de drivers e bibliotecas dinâmicas (IDs dos eventos 6-7). Monitoramento do carregamento em memória de DLLs e drivers de dispositivos, verificação da assinatura digital e sua validade.
Criação de um fluxo em um processo em execução (ID do evento 8). Um dos tipos de ataque que também deve ser monitorado.
Eventos RawAccessRead (ID do evento 9). Operações de leitura do disco usando “.”. Na quase totalidade dos casos, essa atividade deve ser considerada anormal.
Criação de um fluxo de arquivo nomeado (ID do evento 15). O evento é registrado quando um fluxo de arquivo nomeado é criado, gerando eventos com o hash do conteúdo do arquivo.
Criação de named pipe e conexões (IDs dos eventos 17-18). Monitoramento de código malicioso que se comunica com outros componentes através de named pipes.
Atividade de WMI (ID do evento 19). Registro de eventos gerados ao acessar o sistema através do protocolo WMI.
Para proteger o próprio Sysmon, é necessário monitorar eventos com ID 4 (parada e inicialização do Sysmon) e ID 16 (alteração da configuração do Sysmon).
Logs do Power Shell
O Power Shell é uma ferramenta poderosa para gerenciar a infraestrutura do Windows, portanto, há grandes chances de que um atacante escolha exatamente ele. Para obter dados sobre eventos do Power Shell, podem ser usados dois fontes: Windows PowerShell log e Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Fornecedor de dados carregado (ID do evento 600). Os provedores do PowerShell são programas que servem como fonte de dados para o PowerShell, permitindo a visualização e o gerenciamento deles. Por exemplo, provedores integrados podem incluir variáveis de ambiente do Windows ou o registro do sistema. É importante monitorar a adição de novos provedores para detectar atividades maliciosas a tempo. Se, por exemplo, você notar que o WSMan apareceu entre os provedores, significa que uma sessão remota do PowerShell foi iniciada.
Microsoft-WindowsPowerShell / Registro operacional (ou MicrosoftWindows-PowerShellCore / Registro operacional no PowerShell 6)
Registro de módulos (ID do evento 4103). Os eventos contêm informações sobre cada comando executado e os parâmetros com os quais foi chamado.
Registro de bloqueio de scripts (ID do evento 4104). O registro de bloqueio de scripts mostra cada bloco de código do PowerShell executado. Mesmo que um invasor tente ocultar o comando, esse tipo de evento mostrará o comando do PowerShell que foi realmente executado. Além disso, nesse tipo de evento, alguns chamados de API de baixo nível também podem ser registrados, esses eventos geralmente são gravados como Verbose, mas se um comando ou script suspeito for usado em um bloco de código, ele será registrado com a criticidade Warning.
Observe que, após configurar a ferramenta de coleta e análise desses eventos, será necessário mais tempo para depuração a fim de reduzir o número de falsos positivos.
Compartilhe nos comentários quais logs você coleta para auditoria de segurança da informação e quais ferramentas você utiliza para isso. Uma de nossas áreas de atuação são soluções para auditoria de eventos de segurança da informação. Para a tarefa de coleta e análise de logs, podemos sugerir que você conheça , que pode comprimir os dados armazenados com uma taxa de 20:1, e uma única instância instalada é capaz de processar até 60.000 eventos por segundo de 10.000 fontes.
Fonte: habr.com
