Entendendo os casos extremos de protocolos legados no ecossistema Microsoft

By Mirko Peters · 2026-04-26

Protocolos de autenticação legados — como NTLM, SMTP AUTH ou até o velho FTP — podem parecer problemas de outra era, mas teimam em continuar por aí no mundo corporativo centrado na Microsoft…

Automatically translated with AI from the original post. Read the English original

Cover: Detect Microsoft 365 Attack Chains with Entra and Sentinel

Protocolos de autenticação legados — como NTLM, SMTP AUTH ou até o velho FTP — podem parecer problemas de outra era, mas eles continuam firmes e fortes no ambiente corporativo atual, centrado na Microsoft. As organizações modernas migram para o Microsoft 365 e o Azure, mas os casos extremos ligados a esses protocolos minam silenciosamente as iniciativas de confiança zero e as estratégias de segurança. Você pode trancar a porta da frente com autenticação multifator, mas às vezes existe uma janela antiga aberta no porão.

Por que esses casos extremos continuam causando dor de cabeça? A verdade é que a modernização de TI nem sempre acontece da noite para o dia. Muitos sistemas de negócio críticos, integrações com terceiros e até dispositivos de tecnologia operacional estão fixos para usar protocolos mais antigos. Os atacantes sabem disso e, por isso, miram tudo o que ainda está em execução, contornando os controles modernos e abrindo brechas onde as equipes de segurança menos esperam.

Este artigo esmiúça como e por que os riscos dos protocolos legados persistem à medida que as empresas evoluem seus ambientes Microsoft. Vamos definir as peças técnicas, explorar os perigos críticos para o negócio e apresentar o que você pode fazer — da detecção à governança — para resolver de vez essas lacunas teimosas. Vamos lá entender de onde os riscos realmente vêm e como fechar essas portas dos fundos para sempre.

Vulnerabilidades de protocolos legados e exploração no mundo real

Mesmo com as defesas nativas da nuvem e a MFA, os atacantes continuam lucrando com os elos fracos deixados por décadas passadas. Protocolos legados — como o NTLM para autenticação, o SMTP AUTH para e-mail e o FTP ou POP3 básicos para movimentação de dados — continuam por aí porque sistemas reais precisam seguir funcionando enquanto as empresas se modernizam. Os atacantes adoram isso, porque muitas vezes significa que conseguem passar despercebidos pelos sistemas mais bem protegidos da empresa.

Nos ambientes híbridos de hoje, esses protocolos antigos não existem apenas em um servidor escondido no datacenter: eles estão entrelaçados com as plataformas de identidade em nuvem, os aplicativos de linha de negócio e até dispositivos de OT e IoT que simplesmente não conseguem usar autenticação moderna. É difícil eliminá-los gradualmente, já que bloqueá-los de vez pode quebrar algo crítico, e a detecção em todas essas áreas nem sempre é consistente.

O resultado? Incidentes como as violações da Vercel e da Orange España mostram que basta um único protocolo esquecido para abrir a porta para roubo de dados ou comprometimento de rede. Os atacantes usam esses caminhos legados para contornar a MFA, retransmitir credenciais ou escalar permissões tanto em cargas de trabalho na nuvem quanto no local. Vamos detalhar exatamente como esses ataques funcionam, por que os próprios protocolos têm falhas de projeto e onde estão os riscos de negócio mais teimosos.

Também vamos abordar hábitos operacionais que mantêm esses riscos vivos, como depender de uma higiene de políticas frouxa ou herdar anos de dívida técnica de integrações do tipo “só faça funcionar”. As subseções a seguir vão aprofundar como as vulnerabilidades legadas são exploradas, as falhas sistêmicas dos protocolos e onde as defesas modernas esbarram em becos sem saída. Se você busca um ambiente Microsoft realmente seguro, precisa saber exatamente onde essas ameaças antigas se escondem — e como elas continuam entrando quando seus logs dizem que tudo está “seguro”. Para saber mais sobre como esses ataques se encadeiam no mundo real, confira este detalhamento sobre as cadeias de ataque no Microsoft 365.

Como as violações de dados da Vercel e da Orange España expuseram os riscos dos protocolos legados

As violações da Vercel e da Orange España deixaram claro que os riscos dos protocolos legados não são apenas uma preocupação hipotética. Em ambos os incidentes, métodos de autenticação desatualizados tiveram papel central, entregando aos atacantes as chaves para se movimentar mais fundo nas redes corporativas. No caso da Vercel, os atacantes conseguiram extrair variáveis de ambiente e segredos de centenas de clientes de alto perfil, tudo porque credenciais ligadas a fluxos de autenticação legados ainda estavam em uso nos bastidores.

O incidente da Orange España seguiu um padrão semelhante. Dessa vez, os atacantes ultrapassaram as defesas da linha de frente usando credenciais válidas roubadas, muitas das quais não funcionariam se protocolos legados como POP3/IMAP ou SMTP AUTH sem proteção não estivessem habilitados para e-mail. Um relatório anual de ameaças da IBM aponta que o roubo de credenciais continua sendo o principal vetor de acesso inicial em violações de ambientes corporativos, especialmente quando as organizações não desativam proativamente métodos de autenticação obsoletos.

Especialistas que analisam esses casos ressaltam um ponto essencial: as vulnerabilidades de protocolos legados não são apenas resquícios técnicos. Muitas vezes, elas estão profundamente incorporadas a scripts de automação, ferramentas de backup ou até dispositivos embarcados que usam silenciosamente autenticação ultrapassada todos os dias. No caso do ataque à Vercel, por exemplo, protocolos como a autenticação básica e tokens de acesso mal aninhados permitiram que os atacantes contornassem os controles de política modernos e se movimentassem lateralmente depois de entrar na rede.

O que as organizações podem aprender com isso? Violações de grande repercussão reforçam, repetidamente, que proteger os pontos de entrada mais recentes da nuvem não basta. Para ter resiliência de verdade, é preciso eliminar esses caminhos legados ocultos. Enquanto isso não acontecer, os atacantes continuarão priorizando as rotas de acesso mais fáceis e menos protegidas, que muitas vezes estão em execução discreta em segundo plano em ambientes híbridos e multinuvem.

Relays de NTLM e o problema da autenticação básica: contornando os controles de segurança modernos

Protocolos legados como NTLM e a autenticação básica causam muitas dores de cabeça para as equipes de segurança, porque não seguem as regras modernas de MFA. Veja como os agentes de ameaça exploram essas fraquezas para contornar as defesas:

Ataques de relay NTLM:
Os atacantes capturam hashes NTLM em um dispositivo comprometido e os "retransmitem" para outros serviços aos quais a vítima tem acesso. Como o NTLM não exige que a senha original seja conhecida, o atacante pode se passar por usuários sem jamais quebrar uma senha. Esses relays frequentemente vão do AD local para a nuvem, especialmente em configurações de identidade híbrida com segmentação deficiente.
Contornando o MFA:
Protocolos como SMTP AUTH e IMAP não oferecem suporte a MFA. Se um atacante obtiver credenciais válidas, pode fazer login usando esses protocolos, mesmo que o MFA esteja aplicado às contas de usuário. Isso significa que senhas fracas e reutilizadas se tornam um ponto único de falha em ambientes que deveriam ser seguros.
Movimentação lateral e escalonamento de privilégios:
Depois de entrar, os atacantes usam protocolos legados para se movimentar. Por exemplo, explorando a autenticação básica em um aplicativo esquecido, eles podem avançar lateralmente para sistemas com privilégios mais altos. O acesso a um único serviço SMB ou Exchange desprotegido costuma levar ao comprometimento de toda a rede.
Contornando o Acesso Condicional:
Muitas políticas de Acesso Condicional no Azure AD se aplicam apenas a clientes de autenticação moderna. Protocolos legados conseguem passar despercebidos por essas regras, deixando "listas de permissões" perigosas ou lacunas nas políticas que os atacantes procuram ativamente. Quer o aprofundamento sobre ciclos de segurança de identidade e como corrigir a proliferação de políticas de Acesso Condicional? Confira este episódio do podcast sobre redução de riscos escalável em ambientes Microsoft.

Em resumo, você pode configurar e aplicar todos os controles modernos que quiser, mas, se protocolos legados ainda estiverem ativos, os atacantes quase sempre encontrarão uma forma de contornar suas novas defesas.

Falhas sistêmicas: de vulnerabilidades do MCP aos riscos de LLMNR e NetBIOS

Os protocolos legados da Microsoft são assombrados por falhas que não são apenas bugs, mas estão incorporadas ao próprio design. Veja por que essas fraquezas representam um risco persistente:

Falhas do MCP (Microsoft Connector Platform):
Algumas plataformas e conectores usados por agentes de terceiros e scripts de automação ainda dependem de repasse de credenciais legado, sem vinculação adequada de tokens ou controle de acesso granular. Os atacantes exploram isso para escalar privilégios, principalmente quando as políticas dos agentes não são bem governadas.
Fraquezas do LLMNR (Link-Local Multicast Name Resolution):
O LLMNR foi projetado para facilitar a resolução de nomes em redes, mas é facilmente abusado para roubo de credenciais. Os atacantes transmitem respostas falsas, enganando sistemas próximos para que entreguem hashes NetNTLM, que depois podem ser quebrados ou retransmitidos.
Riscos de nomenclatura do NetBIOS:
Redes Windows antigas ainda usam NetBIOS para resolução de nomes — outro protocolo que nunca foi projetado pensando em segurança. Atacantes podem interceptar e manipular o tráfego para se passar por serviços ou obter detalhes sensíveis da rede, preparando novos ataques.
Lacunas na assinatura SMB:
A assinatura SMB foi adicionada para proteger compartilhamentos de arquivos, mas sua aplicação é irregular, principalmente em redes híbridas e ambientes OT. Atacantes aproveitam isso para retransmitir credenciais ou falsificar respostas entre sistemas, muitas vezes saltando da lacuna entre OT legado e a infraestrutura de TI moderna.

Desabilitar protocolos como LLMNR e exigir a assinatura SMB são itens obrigatórios para qualquer iniciativa séria de Zero Trust. Para entender melhor como o controle coordenado e a segurança adaptativa podem ajudar a fechar essas lacunas de protocolo, ouça o episódio do podcast Zero Trust by Design — é um mergulho prático em identidade unificada e controles de sessão.

Autenticação moderna versus legado: desafios de transição e casos extremos

Migrar da autenticação legada para a moderna é uma jornada, não uma troca rápida. Ao fazer essa transição, você vai se deparar com todo tipo de caso extremo. Embora protocolos como OAuth 2 e MFA elevem o nível de segurança, a necessidade de compatibilidade com versões anteriores muitas vezes deixa a porta dos fundos meio aberta. Fluxos de autenticação “semimodernos” — como modelos híbridos ou protocolos que se fazem passar por modernos — aparecem em toda parte, confundindo tanto a conformidade quanto a proteção.

Por que as organizações acabam com essas configurações híbridas? A resposta é simples: aplicativos críticos, serviços e integrações com terceiros nem sempre estão prontos para desligar a autenticação legada da noite para o dia. Às vezes, um processo de negócio simples ou um fluxo de automação herdado depende de métodos de autenticação que datam de décadas. Desabilitar tudo às pressas pode interromper o negócio ou quebrar a conformidade, então abrem-se exceções — e é aí que os atacantes entram.

Zero Trust de verdade significa fechar cada brecha, e não apenas adicionar camadas novas e vistosas. O ponto delicado é que, ao tentar modernizar a autenticação, algumas “atualizações” simplesmente embalam vulnerabilidades antigas em um pacote mais novo, como o BAV2ROPC ou outros fluxos de senha do proprietário do recurso. Lacunas de política e exclusões esquecidas no Acesso Condicional também podem fazer sua segurança parecer moderna no papel, mas deixar os caminhos legados completamente escancarados.

As próximas seções aprofundam os aspectos técnicos dessas configurações semimodernas e mostram onde até os melhores planos de melhoria esbarram em obstáculos do mundo real. Se você está planejando uma transformação de verdade — ou apenas tentando manter os atacantes do lado de fora —, vale entender por que o suporte ao legado morre tão devagar e onde sua estratégia ainda pode deixá-lo exposto. Para dicas sobre como montar linhas de base confiáveis de políticas de Acesso Condicional, veja este conteúdo sobre questões de confiança em políticas.

O mistério do BAV2ROPC e as armadilhas da autenticação semimoderna

BAV2ROPC significa "Basic Authentication Version 2 Resource Owner Password Credential". Parece moderno, mas é apenas uma nova roupagem para um problema antigo. Esse protocolo, frequentemente encontrado em ambientes de nuvem da Microsoft, faz a ponte entre a autenticação legada e a moderna ao permitir que aplicativos enviem programaticamente um nome de usuário e uma senha para obter um token de recurso — sem navegador nem fluxo de consentimento moderno.

Essa abordagem “semimoderna” engana muitas organizações. Na superfície, o BAV2ROPC usa endpoints modernos e fluxos OAuth 2. Mas, por baixo, depende da mesma troca básica de usuário e senha que protocolos legados como POP3, IMAP ou SMTP AUTH utilizam — e raramente oferece suporte a MFA ou Acesso Condicional. Isso deixa a porta aberta para atacantes realizarem password stuffing, replay de credenciais ou ataques de retransmissão do ambiente local para a nuvem.

A detecção é difícil. Nos logs, o tráfego do BAV2ROPC é difícil de distinguir da autenticação moderna verdadeira. Os atacantes sabem disso e miram deliberadamente aplicativos ou contas de serviço que usam esses fluxos, já que tentativas de invasão não disparam os mesmos alarmes da autenticação básica tradicional. Na prática, as organizações têm dificuldade para migrar para longe do BAV2ROPC, especialmente em tarefas de automação sem interface e scripts de integração que ainda fazem parte da operação do dia a dia.

Para equipes de segurança, a maior armadilha é presumir que qualquer coisa rotulada como "OAuth 2" ou "resource owner" é segura por padrão. BAV2ROPC e protocolos semelhantes evidenciam a dura verdade: mesmo APIs modernas e bem elaboradas ainda podem expô-lo às mesmas fraquezas dos protocolos que deveriam substituir. Enquanto você não auditar e migrar completamente todos os casos extremos, essas brechas semimodernas continuam sendo alvos abertos.

Quando as melhorias na autenticação não bastam: a estratégia de segurança morre pelo suporte legado

Atualizar para OAuth 2 e implantar MFA em todo o ambiente parece a solução perfeita, até que o suporte legado introduz uma falha fatal. Pesquisas indicam que mais de 60% das invasões de contas em nuvem no último ano envolveram credenciais válidas usadas por meio de protocolos legados. Mesmo as políticas de Acesso Condicional mais avançadas desmoronam se houver uma exclusão esquecida ou um aplicativo antigo usando autenticação básica nos bastidores.

Especialistas alertam que modernizar a sua pilha de autenticação não se resume a marcar itens de uma lista de recursos. O suporte legado persistente, as políticas mal configuradas ou as contas de serviço não gerenciadas permitem que atacantes contornem defesas que, de outra forma, seriam robustas. Um plano de transição abrangente, que desative ativamente os caminhos antigos, audite as exclusões de política e governe cada endpoint, é a única forma de se manter à frente. Para uma visão prática de como atacantes exploram o consentimento do OAuth e os caminhos legados, leia esta análise detalhada sobre ataques de consentimento no Entra ID e veja por que a boa governança não é automática conferindo este podcast sobre a ilusão da governança no Microsoft 365.

Detectando e monitorando o uso de protocolos legados em ambientes corporativos

Encontrar e monitorar o uso de autenticação legada é como caçar vazamentos escondidos em um sistema de encanamento enorme. É fácil deixar passar conexões residuais de protocolos, porque elas nem sempre aparecem em destaque nos painéis modernos. No entanto, qualquer instância não identificada, seja um script de backup antigo, uma impressora ou um sensor de IoT, dá aos atacantes mais uma chance de entrar.

Para lidar com isso, os ambientes do Microsoft 365 e do Azure oferecem uma série de logs e ferramentas de análise criadas para dar visibilidade profunda. Mas você precisa saber onde procurar e como interpretar resultados que nem sempre gritam "autenticação legada aqui!". Ao combinar logs de entrada, trilhas de auditoria e telemetria personalizada de ferramentas como PowerShell e Python, você obtém um quadro mais completo de onde os protocolos antigos passam despercebidos. Cruzar dados de recursos em nuvem e locais é essencial, já que ambientes híbridos costumam ter relatórios inconsistentes.

O que torna esse desafio ainda mais complicado? Alguns dispositivos de terceiros e de tecnologia operacional (OT) continuam usando protocolos legados silenciosamente e raramente são incluídos nas varreduras de segurança padrão ou nos relatórios analíticos. As equipes de segurança precisam combinar várias técnicas de monitoramento, desde as pastas de trabalho de entrada do Azure até as extrações do Unified Audit Log, para encontrar cada rastro de uso de protocolos. Para um detalhamento prático sobre a auditoria de atividades no seu locatário e por que sinais mais ricos importam para conformidade e segurança, confira este guia sobre o Microsoft Purview Audit.

As subseções a seguir mostram passo a passo como identificar e investigar vestígios de autenticação legada no seu ambiente, além de dicas práticas para gerar telemetria acionável, garantindo que essas vulnerabilidades ocultas não permaneçam ocultas por muito tempo.

Identificando autenticação legada nos logs de entrada do Azure e nas pastas de trabalho analíticas

Detectar autenticação legada nos Logs de Entrada do Azure e nas análises do Entra ID exige uma abordagem proativa. Aqui está uma lista de verificação prática para identificar esses protocolos arriscados em operação:

Filtre por tipo de aplicativo cliente:
Comece pelos Logs de Entrada do Azure AD no portal do Azure. Filtre as entradas por "Client App" para exibir conexões feitas com protocolos legados, como IMAP, POP3, SMTP e "Other clients". Essas entradas costumam se destacar porque não usam fluxos de autenticação baseados em navegador ou modernos.
Procure os métodos de autenticação:
Analise em detalhe os eventos de entrada com "Authentication Method" definido como "Password", mas sem "MFA" ou "Modern Auth". Isso geralmente indica protocolos que contornam o acesso condicional, especialmente em dispositivos antigos ou scripts de automação.
Configure as pastas de trabalho de análise:
Use o Azure Monitor ou as Entra ID Analytics Workbooks para visualizar tendências ao longo do tempo. Crie uma pasta de trabalho personalizada para gerar gráficos do uso de protocolos, destacar picos de autenticação legada e sinalizar conexões de clientes não conformes.
Correlacione com dados de dispositivo e localização:
Cruze os eventos de autenticação legada com informações de dispositivo e a geolocalização dos logins. Combinações inesperadas, como um login com protocolo legado vindo de um país onde sua empresa não opera, merecem uma análise cuidadosa.
Dicas de solução de problemas:
Se os resultados parecerem escassos, verifique lacunas na retenção de logs ou nas políticas. Alguns eventos podem ser filtrados ou não registrados se as configurações de auditoria não forem abrangentes, ou se houver exclusões nas políticas de Acesso Condicional.

Ao repetir essas etapas, você constrói uma visibilidade confiável. Lembre-se: mesmo alguns poucos registros de protocolos legados nos seus logs podem indicar riscos maiores em outros lugares. Então aprofunde a análise e siga os dados para onde eles levarem.

Geração de telemetria com PowerShell, Python e logs de auditoria unificados: exemplos e melhores práticas

Para capturar cada vestígio de atividade de protocolos legados, nada supera a telemetria personalizada. Veja como configurá-la usando PowerShell, Python e o Unified Audit Log da Microsoft:

Consultas no PowerShell para protocolos legados:
Use os cmdlets Get-Mailbox e Get-CASMailbox no Exchange Online para listar usuários com IMAP, POP3 ou SMTP AUTH habilitados. Encapsule-os em scripts para gerar relatórios diários ou semanais, cruzando com os insights dos logs de entrada.
Automação em Python para correlação de logs:
Use scripts em Python para se conectar à API do Microsoft Graph e extrair registros de entrada e de auditoria de caixas de correio. Analise os tipos de aplicativo cliente e as flags de protocolo de autenticação, e então gere anomalias, como contas de serviço sem interface usando autenticação legada.
Log de auditoria unificado para monitoramento centralizado:
Habilite o Microsoft Purview Audit (antigamente chamado de Unified Audit Log) para agregar atividades do Exchange, SharePoint, Teams e outros serviços. Consulte os campos Operation relacionados a conexões de clientes legados ou a tentativas falhas de autenticação legada para um pipeline de detecção consolidado.
Crie visualizações interativas e alertas:
Exporte ou transmita a telemetria para o Microsoft Sentinel ou o Power BI. Crie painéis com regras de alerta que disparem quando houver novo uso de protocolos legados ou quando forem detectadas exposições de credenciais.
Atenção aos pontos de falha:
Desconfie de dados incompletos causados por retenção limitada de logs, lacunas na configuração padrão ou eventos que não são registrados por padrão. Sempre valide sua cobertura com logins de teste usando protocolos legados antes de dar o trabalho por concluído.

Para mais sobre como integrar telemetria à governança e à automação (quando o conteúdo estiver disponível novamente), fique de olho nas atualizações em esta página de automação com PowerShell que está indisponível no momento, ou confira os episódios recentes do podcast sobre arquitetura corporativa para ver o que vem por aí em estratégias de telemetria.

Estratégias de mitigação: bloqueio e desativação de protocolos legados

Saber que você está usando protocolos legados é só a primeira batalha; vencê-la significa desativar esses canais sem derrubar o negócio. A abordagem certa é equilibrar redução de riscos e continuidade operacional. O Microsoft 365 e o Azure AD oferecem ferramentas poderosas, como o Acesso Condicional e as opções administrativas, para bloquear métodos de autenticação ultrapassados em escala corporativa, mas é preciso implantá-las com cuidado.

As duas principais táticas são: usar o Acesso Condicional para bloquear a autenticação legada de forma abrangente e desativar protocolos como SMTP AUTH, IMAP e POP3 para acesso de correio e dispositivos. O segredo está em identificar todas as exceções e fluxos de trabalho afetados antes de desligar tudo, especialmente para contas de serviço, sistemas de correio híbridos locais ou integrações de terceiros que não podem ser modernizadas facilmente. Implantações em fases e atualizações de política direcionadas ajudam a garantir que você não quebre processos críticos enquanto reduz sua exposição a roubo de credenciais e abuso de spam.

Também é fundamental combinar as mudanças de política com a conscientização das áreas de negócio. Comunique-se com as partes interessadas, teste em grupos menores e use análises para comprovar que a mudança não vai paralisar as operações. Nas seções abaixo, você encontrará instruções passo a passo e considerações sobre a aplicação do Acesso Condicional e a desativação de protocolos no Centro de administração do Microsoft 365. Curioso sobre os riscos ocultos quando os hábitos de negócio não são medidos? Confira este podcast sobre desvio de conformidade e aplicação de políticas para mais insights.

Com o plano certo, bloquear protocolos legados não vai apenas cumprir os requisitos de conformidade: você vai dificultar muito a vida dos atacantes que procuram aquela única porta esquecida aberta.

Como bloquear a autenticação herdada com o Acesso Condicional

Bloquear a autenticação herdada com o Acesso Condicional do Azure AD é ao mesmo tempo poderoso e preciso, quando feito corretamente. Veja o que você precisa saber:

As políticas de Acesso Condicional permitem que as organizações bloqueiem explicitamente tentativas de autenticação de protocolos mais antigos, como SMTP AUTH, IMAP, POP3 e clientes de autenticação básica. Você pode definir o escopo dessas políticas para usuários, grupos ou dispositivos e monitorar o possível impacto no negócio no modo "somente relatório" antes de colocá-las em produção. Essa abordagem em etapas dá a chance de identificar dependências que poderiam quebrar caso o bloqueio seja aplicado de forma abrupta.

A Microsoft recomenda criar pelo menos duas políticas principais: uma que bloqueie a autenticação herdada para todos os usuários e uma segunda com exclusões temporárias para contas de serviço ou exceções conhecidas. Os testes são essenciais: comece no modo de monitoramento para observar quais contas e aplicativos tentam entrar com protocolos legados e, só então, passe para a aplicação da política, quando tiver confiança de que apenas fluxos não essenciais serão afetados.

Não se esqueça de revisar e reduzir as listas de permissões amplas e as exceções herdadas, pois elas criam brechas de segurança invisíveis. O monitoramento contínuo e os alertas para tentativas de autenticação herdada ajudam a identificar novos riscos conforme o seu ambiente de TI muda. Para mais boas práticas e uma base sólida de políticas abrangentes, leia esta análise de um especialista sobre como ajustar o Acesso Condicional para um gerenciamento de acesso previsível e seguro.

Resumindo: endurecer o Acesso Condicional é a sua primeira linha de defesa. Apenas faça as mudanças de forma metódica, sempre equilibrando as necessidades do negócio e os objetivos de segurança.

Desativando o SMTP AUTH e os protocolos de e-mail legados no Centro de administração do Microsoft 365

Desativar o SMTP AUTH e outros protocolos de e-mail legados é uma das formas mais rápidas de reduzir o roubo de credenciais e impedir que atacantes enviem spam pelo seu locatário. Veja como fazer, passo a passo:

Auditar o uso atual:
Comece com o PowerShell do Exchange Online (Get-TransportConfig e Get-Mailbox). Identifique as caixas de correio com SMTP AUTH habilitado e os protocolos legados IMAP/POP3 que ainda estejam ativos para usuários ou contas de serviço.
Desativar no nível do locatário:
O Centro de administração do Microsoft 365 agora permite desativar o SMTP AUTH para todo o locatário com uma única configuração. Isso bloqueia todas as novas tentativas de autenticação, a menos que sejam feitas exceções para caixas de correio específicas.
Limpeza direcionada de políticas:
Para usuários ou aplicativos que realmente precisam do SMTP AUTH, restrinja o acesso explicitamente e monitore de perto. Remova as permissões de IMAP/POP3 de todas as contas, exceto das mais essenciais, idealmente de nenhuma.
Testar e comunicar:
Antes de desativar em escala, execute casos de teste e informe os usuários ou os proprietários dos sistemas. Fique atento a chamados no helpdesk relacionados a automações quebradas e, em seguida, trabalhe com essas equipes para atualizar seus processos ou migrá-las para a autenticação moderna.
Monitorar após a implantação:
Verifique os logs de auditoria em busca de tentativas de protocolos legados que falharam. Falhas persistentes podem indicar tentativas de ataque ou dependências de negócio não identificadas, que você precisará resolver.

Este roteiro interrompe a maioria dos ataques corriqueiros de comprometimento de credenciais por e-mail e deixa sua equipe de conformidade bem mais tranquila. Controles fortes desde o início significam menos trabalho de limpeza no futuro.

Governança de segurança e supervisão estratégica sobre o risco de protocolos legados

Blindar protocolos legados não se resume a ajustar configurações técnicas. A gestão de risco de verdade acontece no topo, onde a liderança executiva, as operações de segurança e os arquitetos de TI trabalham juntos para governar o ciclo de vida da tecnologia e das políticas. O problema é que a maioria das grandes organizações depende de uma colcha de retalhos de controles, políticas e fornecedores terceirizados, o que torna difícil aplicar uma supervisão consistente em escala.

Uma estratégia de governança inteligente enfrenta perguntas importantes: como você gerencia o risco quando integrações de terceiros, ferramentas agênticas e TI paralela operam cada uma com suas próprias regras? Como você aplica controles uniformes quando metade dos seus parceiros "confiáveis" ou dispositivos IoT sequer consegue usar autenticação moderna? E como você monitora continuamente o desvio de políticas à medida que o negócio, a força de trabalho e o cenário de segurança evoluem?

É aqui que entram os frameworks de governança virtual, a disciplina de políticas e a inteligência avançada. A liderança não deve apenas definir o tom a partir do topo, mas também implementar verificações reais, desde a avaliação dos provedores de serviço de maior risco até a execução de auditorias e a implantação de automação para detecção e remediação. Com IA e automação avançando mais rápido do que nunca, trata-se de colocar ferramentas, políticas e pessoas na mesma página.

Nas seções a seguir, veremos formas eficazes de CISOs e tomadores de decisão construírem modelos de governança com prioridade para o trabalho remoto, gerenciar os riscos de terceiros e agentes mais imprevisíveis e aproveitar a inteligência moderna para fechar de vez as lacunas de protocolos. Para saber mais sobre como equilibrar inovação e supervisão, veja estas dicas de governança do Power Platform, e entenda como acompanhar automações e agentes que avançam mais rápido do que suas políticas neste episódio sobre um framework prático de governança.

Como os líderes de segurança se protegem dos terceiros de maior risco em um framework de governança virtual

Organizações líderes adotam uma abordagem em camadas e proativa para governar o risco de protocolos legados, especialmente o proveniente de terceiros. Aqui estão quatro estratégias práticas:

Implemente a supervisão de agentes: monitore e audite todas as contas de serviço, agentes e integrações de terceiros que interagem com o seu ambiente. Use identidades exclusivas (como os Entra Agent IDs) para os agentes e aplique contratos rigorosos por meio de plataformas como o Microsoft Connector Platform (MCP). Isso ajuda a evitar o desvio de identidade e a perda de responsabilização, especialmente em integrações com IA (mais sobre governança de agentes aqui).
Aplique políticas de autenticação segura: exija que todos os fornecedores e parceiros usem autenticação moderna, sem exceções para "compatibilidade com legado" sem controles compensatórios aprovados. Revise regularmente as exclusões do Acesso Condicional para dispositivos de terceiros e fluxos baseados em conectores.
Segregue e monitore dispositivos OT/IoT e dispositivos que não podem ser corrigidos: quando você tiver tecnologia operacional ou dispositivos IoT presos a protocolos legados, segmente-os em redes isoladas. Aplique controles compensatórios, como monitoramento de rede e lista de acesso permitido, para reduzir a exposição a ameaças de movimento lateral.
Realize revisões de governança remotas e virtuais: adote frameworks de governança virtual para monitorar, remediar e governar de qualquer lugar. Esses frameworks priorizam revisões regulares, auditorias automatizadas e comunicação clara entre as partes interessadas, algo essencial à medida que mais operações passam a ser híbridas ou remotas.

Ao focar na supervisão em camadas, e não apenas em controles técnicos, CISOs e líderes de TI conseguem mitigar riscos dos cantos mais difíceis de alcançar do seu ecossistema.

Aproveite a inteligência avançada para fortalecer as operações de segurança contra ameaças legadas

Ferramentas de inteligência com IA e análise avançada de ameaças dão às organizações uma nova vantagem para detectar, investigar e responder ao abuso de protocolos legados em escala. Essas plataformas usam machine learning para identificar comportamentos anômalos de autenticação, filtrar rapidamente o uso suspeito de protocolos legados e remediar automaticamente ameaças sem atraso humano.

As equipes modernas de operações de segurança integram dados do Microsoft Sentinel, do Purview Audit e de análises comportamentais baseadas em IA para criar uma visão centralizada da atividade de autenticação, tanto moderna quanto legada. Playbooks automatizados podem disparar respostas para exceções de política, contas de serviço de alto risco ou eventos de retransmissão de credenciais, fechando lacunas antes que os invasores possam explorá-las.

Integrar automação e análise não é uma opção, é uma necessidade. Plataformas de orquestração ajudam a unificar dados de ambientes em nuvem, locais e híbridos, garantindo que até os fluxos de autenticação legada menos conhecidos não passem despercebidos. Isso é ainda mais crítico à medida que agentes de IA e automações em grande escala se multiplicam, aumentando tanto os benefícios quanto os riscos operacionais.

Por fim, aplicar acesso com privilégio mínimo, rotular conteúdo sensível e ampliar o monitoramento de auditoria mantém usuários humanos e máquinas sob controle. Para um guia prático sobre como usar análise avançada e IA para conter ameaças à autenticação legada em ambientes Microsoft, incluindo o Copilot e bots de terceiros, veja este guia detalhado sobre IA governada e conformidade.