Use o playbook de Possível aplicação de senha
As etapas a seguir fornecem instruções sobre as ações, tarefas e subfluxos que estão disponíveis no playbook de Possível aplicação de senha.
Antes de Iniciar
Função necessária:
- sn_si.admin
- flow_designer
Certifique-se de ter instalado o Security Operations Spoke (sn_sec_spoke).
Procedimento
-
Quando o playbook é acionado e começa a ser executado, na Etapa 1, você precisa verificar se as atividades são originadas do endereço IP do cliente.
Identifique os endereços IP que executam o ataque do PasswordSpray. Por exemplo, use os TXIDs (IDs de transação) do alerta e pesquise-os nos logs F5.
-
Na Etapa 2, se as atividades se originaram do endereço IP do cliente, execute as seguintes etapas:
- Na Etapa 3, você precisa iniciar uma revisão pós-incidente do possível ataque de PasswordSpray.
- Na Etapa 4, o fluxo termina.
- Na etapa 5, se as atividades não se originaram do endereço IP do cliente, determine o IP de origem do invasor a partir dos detalhes do alerta.
-
Na etapa 6, você precisa validar a reputação do IP usando as ferramentas da Inteligência de código aberto (OSINT) e o padrão de tráfego desses IPs nos últimos sete dias.
Figura 1. Possível playbook de aplicação de senha - Na Etapa 7, você precisa identificar os nomes de usuário que fizeram login com sucesso usando o ataque de PasswordSpray.
- Na Etapa 8, você precisa identificar o número de logins e padrões com falha.
-
Na Etapa 9, você precisa identificar os indicadores de verdadeiro positivo.
- Verifique o tráfego dos IPs de origem nos últimos 60 dias. Nenhum tráfego histórico pode ser uma indicação de um verdadeiro positivo.
- Verifique os padrões de nome de usuário com falhas de autenticação e a contagem. Quanto maior a contagem, maior a probabilidade de ser um verdadeiro positivo.
- O nome de usuário se parece com uma base de dicionário (começando de A a Z) e pode ter nomes de administrador comuns, como admin, sysadmin, root e assim por diante
- O mesmo nome de usuário pode ter padrões diferentes no ataque de dispersão, como o mesmo alerta, pode ter falhas para john.doe, johnd, jdoe, john_doe, jdoe7 etc., indicando que os invasores adivinham o padrão de nome de usuário com base em casos de uso comuns.
- Observe o agente do usuário e os URIs dos logs F5 na etapa acima e veja se os IOCs estão relacionados aos alertas do Red Condor. Se eles corresponderem, será um evento verdadeiro positivo.
- Na Etapa 10, com base na investigação feita até o momento, você precisa verificar se este é um caso de possível ataque de PasswordSpray ou não.
-
Na Etapa 11, se este for o caso de um possível ataque de Pulverização de Senha, execute as seguintes etapas:
-
Na Etapa 12, você precisa coordenar com as equipes apropriadas para bloquear todas as contas necessárias e investigar atividades mal-intencionadas.
Figura 2. - Na Etapa 13, você precisa iniciar uma revisão pós-incidente do possível ataque do PasswordSpray.
- Na Etapa 14, o fluxo termina.
-
Na Etapa 12, você precisa coordenar com as equipes apropriadas para bloquear todas as contas necessárias e investigar atividades mal-intencionadas.
- Na Etapa 15, você precisa verificar se este não é um caso de possível ataque de PasswordSpray.
-
Na Etapa 16, se este não for um caso de possível ataque de Aplicação de senha, execute as seguintes etapas:
- Na Etapa 17, você precisa documentar as descobertas até o momento.
- Na Etapa 18, você precisa iniciar uma revisão pós-incidente do possível ataque do PasswordSpray.
- Na Etapa 19, o fluxo termina.
- Na etapa 20, você precisa consultar os colegas e o gerente de GIR para obter orientação.
- Na Etapa 21, uma tarefa de resposta é criada para concluir a revisão pós-incidente antes de fechar a tarefa.