Quando o atacante não invade: ele entra com acesso legítimo

Durante muito tempo, a narrativa dominante da segurança foi a da invasão.

O atacante “quebra”, “explora”, “força” uma entrada. Algo visivelmente errado acontece, um exploit, um malware, um alerta barulhento.

Na prática, o cenário mais comum hoje é bem menos cinematográfico.

O atacante entra, com login válido, com acesso permitido e sem disparar alarmes óbvios.

Não porque a empresa não tem controles, mas porque confia demais em acessos que nunca foram reavaliados.

O problema central deixou de ser “como alguém entra” e passou a ser o que acontece quando alguém entra com permissão legítima, mas fora de contexto.

O ataque que começa pedindo acesso

Uma parcela crescente dos incidentes relevantes não começa com exploração técnica sofisticada, mas com processos cotidianos funcionando exatamente como foram desenhados.

Help desks existem para remover fricção. Resetar acessos, contornar bloqueios, resolver urgências.

É justamente aí que o atacante atua.

O chamado parece legítimo. O pedido faz sentido. A urgência é plausível.

“Troquei de celular.”

“Estou viajando.”

“Preciso acessar agora.”

O processo responde como foi treinado para responder: ajudando.

Esse tipo de ataque não explora falha técnica. Explora exceções operacionais, pressão por SLA e confiança implícita em sinais fracos de verificação. Não é uma quebra de segurança no sentido clássico, é o uso correto de um processo que nunca foi desenhado para ambientes hostis.

Quando o help desk vira vetor de acesso inicial, não estamos diante de ausência de controle. Estamos diante de uma confiança mal governada.

MFA funciona, até o momento em que não funciona mais

A autenticação multifator continua sendo essencial, mas ela não é um fim em si mesma.

Hoje, muitos ataques não tentam contornar o MFA; eles operam depois dele.

Phishing em tempo real, proxies adversários e engenharia social permitem que o usuário faça o login “corretamente”, complete o MFA e, ainda assim, entregue algo muito mais valioso do que a senha: a sessão.

Nesse cenário, trocar a senha não resolve. Forçar novo MFA não resolve.

O atacante já não precisa autenticar de novo. Ele herdou um acesso válido, aceito pelo sistema.

O problema não é o MFA estar “errado”. O problema é tratá-lo como proteção absoluta, quando ele é apenas uma etapa dentro de um ciclo maior de acesso.

Sessões e tokens: o ativo invisível

Em ambientes modernos, a unidade real de acesso não é mais a senha, é a sessão.

Sessões, cookies e tokens representam acesso ativo, contextualizado e com baixa fricção. Para o atacante, roubá-los é mais eficiente do que roubar credenciais: a senha pode ser trocada, o MFA pode bloquear uma nova tentativa e a sessão válida permite agir imediatamente.

Por isso, ataques bem-sucedidos hoje se concentram menos em “entrar” e mais em permanecer. E permanecer significa manter sessões ativas, criar persistência e expandir alcance com o menor ruído possível.

Quando a resposta ao incidente não considera revogação de sessões, invalidação de tokens e reversão de alterações silenciosas, a organização reage, mas o acesso continua existindo.

Privilégios: o capital acumulado do ataque

Uma vez dentro, o atacante busca o mesmo que qualquer operador racional buscaria: alavancagem.

Privilégios excessivos, acessos herdados, contas administrativas permanentes e exceções antigas funcionam como capital acumulado. Cada permissão desnecessária amplia o raio de ação semexigir novas etapas de ataque.

Na maioria das organizações, esse cenário não existe por negligência, mas por conveniência operacional. Acesso concedido “temporariamente”. Exceção que nunca foi revisada. Conta criada para resolver um problema específico e nunca desativada.

Nada disso parece crítico isoladamente. Em conjunto, forma um caminho limpo para movimentação lateral, persistência e impacto real.

O fio condutor: confiança sem governo

Quando se observa esse tipo de incidente de ponta a ponta, um padrão fica claro.

Não é falta de tecnologia.

Não é ausência de controles.

Não é desconhecimento de boas práticas.

É confiança distribuída sem governança contínua.

Confiança em processos que não foram pensados para adversários persistentes.

Confiança em acessos que nunca foram reavaliados.

Confiança em exceções que viraram regra.

Segurança falha menos por ausência de controle e mais por confiança mal governada.

Governar confiança é uma decisão, não um produto

Reduzir esse risco não passa por adicionar mais uma ferramenta isolada. Passa por decisões estruturais: endurecer processos de recuperação de acesso e help desk, tratar sessões como ativos que precisam ser controlados e revogados, limitar privilégios no tempo e no escopo e revisar exceções com a mesma seriedade que se revisa incidentes.

Isso não elimina fricção, mas substitui o improviso por disciplina.

Em um cenário onde o atacante não precisa mais “invadir”, decidir bem sobre quem pode acessar, por quanto tempo e em quais condições se torna o verdadeiro diferencial de segurança.

E essa é, cada vez mais, uma decisão de negócio, não apenas de tecnologia.

Fontes

MITRE ATT&CK — T1078: Valid Accounts

CISA — Cybersecurity Advisory AA23-320A: Scattered Spider

Microsoft Security Blog (21 jan 2026) — Multi-stage AiTM phishing e BEC abusando de SharePoint

CISA — Fact Sheet: Implementing Phishing-Resistant MFA

MITRE ATT&CK — T1539: Steal Web Session Cookie

MITRE ATT&CK — T1185: Browser Session Hijacking

Microsoft Learn — Continuous Access Evaluation (CAE) no Microsoft Entra

Microsoft Learn — Token Protection no Microsoft Entra Conditional Access