Monitorização de acessos privilegiados é o processo de vigiar continuamente contas com poderes administrativos — root, sudoers, administradores de domínio, papéis de cloud e tokens de API — porque elas concentram em um único lugar a capacidade de desativar controles, apagar evidências e mover dados. No SOC, essa vigília é tratada como prioridade de detecção: de acordo com o MITRE ATT&CK, adversários obtêm e abusam de credenciais de contas existentes como meio de obter acesso inicial, persistência, escalada de privilégios e evasão de defesa (técnica T1078, Valid Accounts, versão 3.0), muitas vezes sem usar malware algum. Este artigo mostra como estruturar essa vigilância em camadas: inventário de contas, sinais de alerta, engenharia de regras e resposta.
Inventário antes da detecção
Nenhum alerta funciona sem a pergunta mais básica: quem tem privilégio, de que tipo, e por que motivo. O erro comum é reduzir o escopo a contas de domínio; acessos privilegiados hoje incluem papéis de IaaS, chaves de service account, tokens de CI/CD e membros de grupos como ESX Admins. O caso do grupo Scattered Spider, que adicionava contas ao grupo ESX Admins para obter direitos totais no vSphere, documentado na própria página da técnica T1098 do MITRE, mostra que o alvo privilegiado nem sempre é o domínio Windows — hipervisores e consoles de virtualização contam, e muito.
Comece com uma tabela viva, mantida pelo SOC junto ao time de identidade, com no mínimo estas colunas:
| Conta ou papel | Tipo de privilégio | Dono | Uso esperado | Janela de uso |
|---|---|---|---|---|
| svc-backup | Leitura de snapshots | Infra | Cron noturno | 00:00–05:00 |
| adm-jump | Admin de domínio | IdM | Só via jump host | Horário comercial |
| deploy-ci | Escrita em repositório | Plataforma | Pipelines | Sob demanda |
Sem essa baseline, qualquer regra de correlação vira ruído: o SOC não consegue distinguir login administrativo legítimo de abuso, porque nunca definiu o que é legítimo.
Sinais que merecem alerta
A técnica T1098, Account Manipulation, versão 2.8, descreve adversários que manipulam contas para manter ou elevar acesso — editar credenciais, alterar grupos de permissão, fazer atualizações iterativas de senha para driblar políticas de expiração. A página do MITRE lista detecções concretas para essa técnica, incluindo cadeias de comportamento que correlacionam mudanças em atributos de conta com linhagem de processo incomum, uso de ferramentas nativas como usermod, passwd e groupmod para escalar permissões, e elevação de papéis em ambientes de colaboração e cloud. Traduzido para sinais de SOC:
- Uso fora de janela: conta privilegiada ativa em horário sem manutenção agendada.
- Mudança de grupo ou papel: adição a grupo administrativo ou promoção de papel ReadOnly para Admin, especialmente fora do fluxo de mudança.
- Conta inativa reativada: o MITRE destaca que adversários abusam de contas inativas, como as de pessoas que já saíram da organização, justamente porque o dono original não está lá para notar atividade anômala.
- Rota de acesso incomum: login privilegiado vindo de IP, host ou método de autenticação nunca visto antes para aquela conta.
Regras em Wazuh e Sigma
Do lado do motor de análise, o trabalho se apoia em ferramentas abertas. A documentação do Wazuh descreve que a plataforma coleta logs de endpoints, containers e cloud, processa esses dados com decoders que normalizam o log bruto em campos estruturados, e compara os campos contra seu ruleset disparando alertas quando condições são atendidas — os alertas ficam gravados em /var/ossec/logs/alerts/alerts.json no servidor Wazuh e podem ser consultados no dashboard. A mesma documentação informa que o produto traz mais de 3000 regras e decoders prontos e recomenda escrever regras customizadas em /var/ossec/etc/rules/local_rules.xml, nunca dentro do diretório do ruleset embutido, que é sobrescrito na atualização. Para sudo e escaladas em Linux, o caminho prático é coletar os logs auth do agente, decodificar o campo de usuário e comando, e criar regra customizada com frequência sobre falhas seguidas de sucesso — o padrão clássico de quem testa privilégio.
Para compartilhar e versionar detecções entre SIEMs, o formato aberto certo é o Sigma: o projeto se descreve como um formato genérico, aberto e estruturado de detecção que permite a equipes de segurança detectar eventos relevantes de log de forma simples e compartilhável. Uma regra Sigma típica declara logsource (por exemplo, produto aws, serviço cloudtrail), uma seleção de campos como userIdentity.type: Root, um filtro para eventos legítimos e um condition que combina os dois — e o mesmo YAML é convertido com um comando para a sintaxe do backend de destino, como Splunk. A disciplina que vale aqui: cada regra de acesso privilegiado no seu repositório carrega a técnica ATT&CK correspondente no campo tags, o que liga o alerta à cobertura que você mede.
Plano de resposta em cinco etapas
Quando um alerta de conta privilegiada dispara, a resposta precisa ser ensaiada, não improvisada:
- Conter sem destruir: revogue sessões e tokens da conta, mas preserve a VM ou host para perícia; não reinicie antes de capturar memória se houver indício de abuso ativo.
- Confirmar escopo: liste tudo que a conta tocou desde o primeiro evento suspeito — logins, mudanças de grupo, criação de chaves, dumps de repositório.
- Buscar persistência: verifique contas novas, alterações em sudoers, chaves SSH autorizadas e agendamentos criados no período.
- Restaurar confiança: rotação de credenciais dependentes, revisão de permissões herdadas e MFA reafirmado nos caminhos administrativos.
- Fechar o ciclo: documente o caso, ajuste a regra que atrasou ou faltou, e volte ao inventário para decidir se aquele privilégio precisava existir.
O incidente quase sempre revela privilégio que ninguém usava legitimamente — a melhor regra de detecção continua sendo remover o acesso que sobrou.
Erros que anulam a monitorização
Três falhas repetem-se em operações: confundir qualidade de logs com volume de logs — sem o evento de autenticação privilegiada coletado do host certo, nenhuma correlação nasce; deixar contas de serviço fora do inventário porque não têm dono óbvio; e alertar apenas sobre falha de login, ignorando que o ataque bem-sucedido com credencial válida não gera nenhuma falha. Sobre esse último ponto vale a leitura dos nossos textos sobre bypass de MFA pelo ransomware Gunra e sobre detecção de movimento lateral com pass-the-hash, que cobrem os casos em que a credencial legítima é o próprio vetor.
