Use este playbook para investigar alertas de spam de senha acionados por vários logins com falha (muitas falhas de autenticação de mais de um endereço IP para o mesmo usuário). As etapas a seguir fornecem um passo a passo das ações, tarefas e subfluxos que estão disponíveis no playbook de Possível senha de spam.
Antes de Iniciar
Função necessária:
sn_si.admin
flow_designer
Verifique se você instalou o Spoke das Operações de segurança (sn_sec_spoke).
Procedimento
Quando o playbook é acionado e começa a ser executado, na Ação 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 de spam de senha. Por exemplo, use os TXIDs (IDs de transação) do alerta e pesquise-os em relação aos logs F5.
Na Ação 2, se as atividades foram originadas do endereço IP do cliente, execute as seguintes ações:
Na Ação 3, você precisa iniciar uma revisão pós-incidente do possível ataque de spam de senha.
Na Ação 4, o fluxo termina.
Na Ação 5, se as atividades não tiverem origem no endereço IP do cliente, determine o IP de origem do invasor a partir dos detalhes do alerta.
Na Ação 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 spam de senha
Na Ação 7, você precisa identificar os nomes de usuário que fizeram login com sucesso usando o ataque de spam de senha.
Na Ação 8, você precisa identificar o número de logins e padrões com falha.
Na Ação 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 spam, 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 positivo verdadeiro.
Na Ação 10, com base na investigação feita até o momento, você precisa verificar se este é um caso de possível ataque de spam de senha ou não.
Na Ação 11, se este for o caso de um possível ataque de spam de senha, execute as seguintes ações:
Na Ação 12, você precisa coordenar com as equipes apropriadas para bloquear todas as contas necessárias e investigar atividades mal-intencionadas.
Figura 2. Possível playbook de spam de senha
Na Ação 13, você precisa iniciar uma revisão pós-incidente do possível ataque de spam de senha.
Na Ação 14, o fluxo termina.
Na Ação 15, você precisa verificar se este não é um caso de possível ataque de spam de senha.
Na Ação 16, se este não for um caso de possível ataque de spam de senha, execute as seguintes ações:
Na Ação 17, você precisa documentar as descobertas até o momento.
Na Ação 18, você precisa iniciar uma revisão pós-incidente do possível ataque de spam de senha.
Na Ação 19, o fluxo termina.
Na Ação 20, você precisa consultar os colegas e o gerente do GIR para obter orientação.
Na Ação 21, uma tarefa de resposta é criada para concluir a revisão pós-incidente antes de fechar a tarefa.