Pontos cegos no log de autenticação em nuvem

Uma equipe de segurança da TrustedSec divulgou recentemente o terceiro e o quarto métodos para contornar o registro de sign-in do Azure. São quatro técnicas independentes para se autenticar nos serviços cloud da Microsoft sem que a autenticação apareça nos logs nos quais as equipes de segurança confiam para detecção. O login aconteceu. O log não registrou. Quem monitorava esses logs em busca de atividade suspeita não viu nada.

Isso não é um problema teórico. Se um atacante roubar credenciais e usá-las para acessar seu ambiente Azure, a primeira coisa que sua equipe de segurança faz é verificar os logs de sign-in. Se esses logs estiverem incompletos — se categorias inteiras de autenticação não gerarem registros —, sua capacidade de detecção tem um buraco que você não conhecia. E você vem tomando decisões de segurança com base na suposição de que os logs estavam completos.

Por que os logs de autenticação têm lacunas

A suposição ingênua é que o log de autenticação é simples: alguém se autentica, você registra. Na prática, a autenticação em nuvem é um sistema extenso, com dezenas de protocolos, endpoints e tipos de token, e a cobertura de log varia entre eles.

O Azure Active Directory (agora Entra ID) cuida da autenticação do Microsoft 365, dos recursos do Azure, de apps de terceiros via SAML/OIDC, de aplicações legadas on-premises via App Proxy, de service principals, de managed identities e de muito mais. Cada um desses caminhos tem seu próprio backend, seu próprio pipeline de log e seus próprios casos de borda. Os logs de sign-in são gerados pelo serviço de autenticação, mas alguns fluxos passam ao largo do serviço padrão ou usam caminhos legados que são anteriores à infraestrutura de log atual.

Lacunas em protocolos legados

A Microsoft mantém compatibilidade retroativa com protocolos de autenticação do início dos anos 2000, protocolos que são anteriores à sua infraestrutura moderna de log. Alguns caminhos de autenticação SMTP, IMAP e POP3 usam fluxos de 'Basic Auth' que autenticam na camada de transporte de e-mail, e não pelo endpoint de token padrão do Azure AD. Essas autenticações podem não gerar as mesmas entradas de sign-in que os fluxos OAuth/OIDC modernos geram.

A Microsoft vem descontinuando o Basic Auth há anos, mas a desativação é lenta em ambientes corporativos. Organizações com clientes de e-mail legados, scanners que enviam documentos por e-mail ou aplicações de negócio mais antigas podem ainda ter o Basic Auth habilitado. Cada caminho legado é uma potencial lacuna de log.

Autenticação de service principals

Service principals, identidades não humanas usadas por aplicações e automações, se autenticam de forma diferente dos usuários. Seus eventos de sign-in aparecem em um fluxo de log separado (sign-ins de service principals versus sign-ins interativos e não interativos). Equipes de segurança que monitoram apenas o log de sign-in interativo simplesmente não enxergam a atividade de service principals.

Isso importa porque service principals comprometidos são um vetor de ataque comum. Um atacante que obtém as credenciais ou o certificado de um service principal consegue se autenticar como aquela aplicação e acessar tudo o que ela tem permissão de acessar. Se a equipe de segurança está olhando apenas os sign-ins de usuários, nunca vai ver isso.

Replay e renovação de tokens

Nem todo acesso envolve uma autenticação nova. Refresh tokens do OAuth permitem acesso contínuo sem reautenticar. Se um atacante roubar um refresh token válido (por meio de um dispositivo comprometido, tráfego interceptado ou malware), ele pode trocá-lo por novos access tokens sem disparar as mesmas entradas de sign-in que uma autenticação por senha geraria. O sign-in inicial foi registrado, mas as renovações de token seguintes podem aparecer como sign-ins não interativos, que muitas regras de detecção simplesmente não monitoram.

O problema da engenharia de detecção

As lacunas no log de autenticação revelam um problema maior na segurança em nuvem: construímos sistemas de detecção sobre logs que presumimos completos e depois ficamos surpresos quando atacantes encontram caminhos que não geram log nenhum.

A arquitetura de segurança padrão para ambientes em nuvem funciona assim: os serviços cloud geram logs → os logs vão para um SIEM (Security Information and Event Management) → regras de detecção analisam os logs em busca de padrões suspeitos → alertas disparam uma investigação. Isso só funciona se os logs capturarem toda a atividade relevante. Se não capturarem, seu SIEM é uma forma muito cara de monitorar uma visão incompleta.

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

O que você pode fazer de fato

Você não consegue corrigir as lacunas de log do provedor de nuvem, isso é trabalho da Microsoft (ou da AWS, ou do Google). Mas você pode construir estratégias de detecção que não dependam exclusivamente de os logs de autenticação estarem completos.

Monitore múltiplas fontes de log

Os logs de autenticação são um sinal. Os logs de atividade são outro. Mesmo que o sign-in de um atacante não apareça nos logs de autenticação, as ações seguintes dele (ler e-mails, acessar arquivos, consultar bancos de dados, alterar configurações) geram suas próprias entradas. Cruzar logs de atividade com logs de autenticação revela inconsistências: atividade de uma identidade sem um sign-in recente correspondente é suspeita, não importa por que o sign-in não foi registrado.

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

Desative a autenticação legada

Se você não usa protocolos legados (Basic Auth para SMTP, IMAP, POP3), desative-os. Isso elimina categorias inteiras de lacunas de log, porque os caminhos de autenticação que contornam o log moderno simplesmente não podem mais ser usados. As políticas de Acesso Condicional do Azure podem bloquear a autenticação legada por usuário, por grupo ou para todo o tenant.

Antes de desativar, audite o uso atual. Ironicamente, os logs de sign-in do Azure mostram algumas tentativas de autenticação legada, e o workbook do Entra ID para autenticação legada ajuda a identificar aplicações que ainda usam protocolos antigos. Corrija essas aplicações primeiro e só então bloqueie a autenticação legada.

Monitore a atividade de tokens

Implemente o Continuous Access Evaluation (CAE) se o seu ambiente suportar. O CAE permite que o Azure AD revogue tokens em quase tempo real quando as condições mudam (usuário desabilitado, sign-in de alto risco detectado, mudança de localização de IP). Sem o CAE, um access token roubado continua válido até expirar, normalmente após uma hora, independentemente do que a equipe de segurança faça.

Monitore também o tempo de vida dos tokens e os padrões de renovação. Um refresh token usado a partir de um novo endereço IP, de um novo dispositivo ou em horários incomuns deve ser sinalizado, pois isso costuma ser o único sinal de roubo de token.

Teste o seu próprio log

A coisa mais impactante que você pode fazer é testar regularmente se o seu log realmente captura o que você imagina. Autentique-se por cada método que o seu ambiente suporta (interativo, não interativo, service principal, protocolo legado) e verifique se cada um gera as entradas de log esperadas. Se não gerar, você encontrou uma lacuna antes de um atacante encontrar.

Isso é uma forma de teste em engenharia de detecção que poucas organizações fazem de forma sistemática. A maioria das equipes escreve regras de detecção e presume que elas funcionam. Validar a qualidade dos dados subjacentes, confirmando que os eventos das quais suas regras dependem estão de fato sendo registrados, é provavelmente mais importante do que as próprias regras.

A lição mais ampla

Os bypasses de log de sign-in do Azure não são exclusivos da Microsoft. Todo provedor de nuvem tem caminhos de autenticação com log incompleto. O AWS CloudTrail tem lacunas conhecidas próprias, como certas operações do plano de controle em algumas regiões, certas assunções de service-linked roles e padrões de encadeamento de roles entre contas que podem ocultar a identidade original. Os logs de auditoria do Google Cloud têm casos de borda semelhantes.

A lição não é 'o log do Azure está quebrado'. É que todo log é incompleto, e arquiteturas de segurança que presumem o contrário vão falhar. Defesa em profundidade não é apenas ter múltiplos controles de segurança, é ter múltiplas fontes independentes de visibilidade. Se a sua detecção depende inteiramente de uma fonte de log estar completa, você tem um ponto único de falha na sua postura de segurança.

Construa sua detecção partindo da premissa de que qualquer fonte de log individual pode estar incompleta ou ser contornada. Correlacione logs de autenticação, logs de atividade, logs de rede e telemetria de endpoints. Procure inconsistências entre as fontes, pois elas frequentemente apontam exatamente para as lacunas que atacantes exploram. E teste seus logs regularmente, porque a lacuna que você não conhece é aquela que será usada contra você.