Use o playbook de Possível aplicação de senha

  • Versão de lançamento: Washingtondc
  • Atualizado 1 de fev. de 2024
  • 2 min. de leitura
  • 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

    1. 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.
    2. Na Etapa 2, se as atividades se originaram do endereço IP do cliente, execute as seguintes etapas:
      1. Na Etapa 3, você precisa iniciar uma revisão pós-incidente do possível ataque de PasswordSpray.
      2. Na Etapa 4, o fluxo termina.
    3. 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.
    4. 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
      Tarefas de resposta para validar a reputação do IP usando as ferramentas OSINT.
    5. Na Etapa 7, você precisa identificar os nomes de usuário que fizeram login com sucesso usando o ataque de PasswordSpray.
    6. Na Etapa 8, você precisa identificar o número de logins e padrões com falha.
    7. 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.
    8. 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.
    9. Na Etapa 11, se este for o caso de um possível ataque de Pulverização de Senha, execute as seguintes etapas:
      1. Na Etapa 12, você precisa coordenar com as equipes apropriadas para bloquear todas as contas necessárias e investigar atividades mal-intencionadas.
        Figura 2.
        Tarefas de resposta para bloquear todas as contas necessárias e investigar atividades mal-intencionadas.
      2. Na Etapa 13, você precisa iniciar uma revisão pós-incidente do possível ataque do PasswordSpray.
      3. Na Etapa 14, o fluxo termina.
    10. Na Etapa 15, você precisa verificar se este não é um caso de possível ataque de PasswordSpray.
    11. Na Etapa 16, se este não for um caso de possível ataque de Aplicação de senha, execute as seguintes etapas:
      1. Na Etapa 17, você precisa documentar as descobertas até o momento.
      2. Na Etapa 18, você precisa iniciar uma revisão pós-incidente do possível ataque do PasswordSpray.
      3. Na Etapa 19, o fluxo termina.
    12. Na etapa 20, você precisa consultar os colegas e o gerente de GIR para obter orientação.
    13. Na Etapa 21, uma tarefa de resposta é criada para concluir a revisão pós-incidente antes de fechar a tarefa.