Security Center:Detectar logins de contas inativas com regras SQL personalizadas

Definir atividade recente

(
  select
    user_id,
    src_ip,
    username,
    uuid,
    start_time
  from
    log
  where
    cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 20 * 60
    and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint)
) a

• Análise de sintaxe:

  • from log: Consulta dados da tabela log.

  • to_unixtime(current_timestamp): Retorna o timestamp Unix atual (em segundos).

  • cast(... as bigint): Converte o timestamp para bigint para permitir operações aritméticas e comparações.

  • where ...: Define uma janela deslizante de 20 minutos terminando no momento atual.

    • >= ... - 20 * 60: O start_time deve ser igual ou posterior ao horário atual menos 20 minutos.

    • < ...: O start_time deve ser anterior ao horário atual.

• Análise semântica:

  • Finalidade: Define um conjunto de resultados chamado a para "atividade recente", que representa os objetos primários da análise.

  • Resultado: Um conjunto de resultados temporário contendo usuários ativos nos últimos 20 minutos, incluindo user_id e src_ip.

  • Ponto-chave: O período "recente" corresponde a uma janela deslizante de 20 minutos que termina no momento atual.

Estabelecer uma linha de base histórica

(
  select
    user_id,
    username,
    uuid
  from
    log
  where
    schema='HOST_LOGIN_ACTIVITY' and
    cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 24 * 3600
    and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint) - 20 * 60
) b

• Análise de sintaxe:

  • schema='HOST_LOGIN_ACTIVITY': Filtra apenas logs de atividade de login em hosts, aumentando a precisão da linha de base.

  • where ...: Define um intervalo de tempo de 24 horas atrás até 20 minutos atrás.

    • >= ... - 24 * 3600: O horário inicial deve ser igual ou posterior ao horário atual menos 24 horas.

    • < ... - 20 * 60: O horário inicial deve ser anterior ao horário atual menos 20 minutos.

• Análise semântica:

  • Finalidade: Constrói um conjunto de "linha de base histórica" denominado b para servir como referência na identificação de atividades anormais.

  • Resultado: Um conjunto de resultados temporário com usuários que fizeram login nas últimas 24 horas, excluindo os 20 minutos mais recentes.

  • Ponto-chave: A janela abrange de 24 horas atrás até 20 minutos atrás, garantindo que não haja sobreposição com os dados de atividade recente e evitando erros de autocomparação.

Usar LEFT JOIN para comparação de diferenças

... a
left join
... b on a.username = b.username and a.uuid = b.uuid and a.user_id = b.user_id

• Análise de sintaxe:

  • LEFT JOIN: Utiliza a tabela à esquerda (a, usuários recentes) como base e correlaciona cada registro com a tabela à direita (b, usuários históricos).

  • on a.username = b.username and a.uuid = b.uuid and a.user_id=b.user_id: Realiza a união baseada em username, uuid e user_id combinados para identificar exclusivamente uma entidade de usuário.

• Análise semântica:

  • Finalidade: Correlaciona a "atividade recente" (a) com a "linha de base histórica" (b) para localizar registros históricos de login para cada usuário recente.

  • Resultado: Um conjunto de resultados combinado contendo todos os registros da tabela a e os registros correspondentes da tabela b.

  • Ponto-chave: O LEFT JOIN é assimétrico: se um usuário da tabela a não tiver correspondência na tabela b, todas as colunas da tabela b retornarão NULL. Esse é o mecanismo central para identificar novas atividades.

Filtrar o resultado final

where
  (
    b.username is null
    or b.username = ''
  )

• Análise de sintaxe:

  • b.username is null: Aproveita o comportamento do LEFT JOIN. Quando um usuário recente (tabela a) não possui correspondência na linha de base histórica (tabela b), o campo b.username assume o valor NULL.

  • or b.username = '': Uma condição defensiva para casos em que um campo de log contém uma string vazia '' em vez de NULL.

• Análise semântica:

  • Finalidade: Filtra os resultados da união para isolar atividades que surgiram recentemente, mas não possuem registro histórico.

  • Resultado: Permanecem apenas os registros sem correspondência do LEFT JOIN, que representam os eventos anormais buscados.

  • Ponto-chave: A condição b.username is null atua como o ponto de decisão central da lógica de detecção. Ela utiliza os valores NULL resultantes da união para separar do conjunto de dados os registros classificados como "presentes recentemente, ausentes historicamente".

SELECT DISTINCT: Gerar alertas

select distinct
     a.user_id,
     a.src_ip,
     a.username,
     a.uuid

• Análise de sintaxe:

  • SELECT DISTINCT: Seleciona os campos especificados e remove duplicatas, garantindo apenas um alerta por evento anormal.

• Análise semântica:

  • Finalidade: Formata e gera uma lista final de eventos anormais para disparo de alertas.

  • Resultado: Uma lista de alertas deduplicada. Cada registro contém as informações essenciais de rastreamento: ID do usuário e IP de origem.

  • Ponto-chave: O uso de DISTINCT deduplica os resultados para que o comportamento anormal do mesmo usuário dentro da janela de detecção de 20 minutos dispare apenas um alerta.

Consulta SQL final

*|set session mode=scan;
select distinct
     a.user_id,
     a.src_ip,
     a.username,
     a.uuid
   from
     (
       select
         user_id,
         src_ip,
         username,
         uuid,
         start_time
       from
         log
       where
         cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) -20 * 60
         and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint)
     ) a
     left join (
       select
         user_id,
         username,
         uuid
       from
         log
       where
         schema='HOST_LOGIN_ACTIVITY' and
         cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 24 * 3600
         and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint) -20 * 60
     ) b on a.username = b.username
     and a.uuid = b.uuid
     and a.user_id=b.user_id
   where
     (
       b.username is null
       or b.username = ''
     )

Configure a regra no Agentic SOC

1. Adquirir e ative o Agentic SOC

   Consulte Adquirir e ativar para visualizar as opções de compra. Para acessar todos os recursos de detecção de ameaças personalizadas, recomendamos adquirir tanto o Log Ingestion Traffic quanto a Log Storage Capacity.

2. Fazer login no console e acesse a página Create Custom Rule

   1. Faça login no .

   2. No painel de navegação à esquerda, escolha Agentic SOC > Detection Rules. No canto superior esquerdo do Console, selecione a Região onde seus ativos estão localizados: Chinese Mainland ou Outside Chinese Mainland.

   3. Na aba Custom, clique em Create Custom Rule.

3. Configure a regra de geração de alertas

   1. No painel Create Custom Rule, na aba Basic Information, insira um nome e uma descrição para a regra e clique em Next para ir à página Alert Settings.

   2. Configure a regra de detecção SQL com as seguintes definições:

      Parâmetro	Valor
      Rule Body	SQL
      Log Scope	Logon Logs - Host Logon Success Log.
      SQL Query	Copie o código da seção Consulta SQL final.
      Scheduling Interval	Fixed Interval - 20 minutes.
      SQL Time Window	24 hours.
      Start Time	When the rule is enabled.
      Generation Structure	Other Alert Logs.
      Alarm Metric	Abnormal Logon.
      Alert Severity	Medium.
      ATT&CK Tactic	Persistence - T1136 Create Account.
      Entity Mapping	Network Address is_malware: 1 ip: $src_ip net_connect_dir: in Host is_asset: 1 uuid: $uuid

4. Configure a regra de geração de incidentes

   1. Na página Alert Settings, após concluir a configuração, clique em Next para ir à página Incident Generation Settings.

   2. Configure a regra de tempo com as seguintes definições:

      • Generate Event: Yes.

      • Incident Generation Method: Aggregate by type.

      • Aggregation Window: 20 minutes.

5. Validar a regra

   Novas regras vêm Disabled por padrão. Teste-as primeiro para avaliar a eficácia. Durante o teste, o sistema calibra automaticamente os campos de alerta. Utilize as sugestões de calibração para otimizar a SQL da regra ou o playbook antes de ativá-la.

   1. Altere o Enabling Status da regra desejada para Testing.

   2. Na coluna de ações da regra alvo, clique em View Alert Test Result.

   3. Visualize o gráfico de tendência de alertas e a lista de alertas gerados na página de detalhes do resultado do teste.

   4. Na coluna Actions de um alerta, clique em Details para visualizar seus resultados de calibração.

6. Ative a regra personalizada

   Após a aprovação da regra nos testes, defina seu Enabling Status como Enabled.

   Importante

   Teste a regra antes de ativá-la.