Segurança do Outlook Web App: proteja o Exchange com a autenticação multifatorial (MFA)

Introdução

A maioria das discussões sobre segurança de acesso remoto começa com a VPN. Quase nenhuma delas começa com o Outlook Web App, e essa é uma lacuna estranha, considerando o que o OWA realmente é: um formulário de login para e-mail corporativo, disponível na internet aberta, acessível a partir de qualquer navegador em qualquer dispositivo, em qualquer lugar. Não há nenhum cliente VPN para configurar, nenhuma regra de firewall para contornar, nenhum segmento de rede pelo qual passar — apenas um campo de nome de usuário, um campo de senha e o que quer que o servidor Exchange decida aceitar.

Para um invasor, isso é o mais próximo possível de um caminho direto para uma caixa de correio. Um login comprometido no OWA não precisa de movimento lateral para se tornar perigoso — ele já é perigoso, imediatamente, porque a própria caixa de correio é o alvo. O comprometimento de e-mails corporativos não precisa de malware, não precisa de uma exploração de vulnerabilidade e não aciona a maioria das ferramentas de detecção criadas para invasões de rede. Ele precisa apenas de um conjunto de credenciais válidas e de uma página de login que não peça mais nada.

Por que o Exchange local e híbrido não recebem a MFA gratuitamente

A confusão aqui é compreensível, pois os locatários do Microsoft 365 que usam o Exchange Online realmente recebem autenticação forte quase automaticamente — as políticas de Acesso Condicional do Entra ID podem exigir MFA na camada de identidade antes mesmo que um token de sessão seja emitido, e essa proteção se estende ao Outlook na web sem qualquer configuração específica do Exchange. Equipes de segurança que sempre trabalharam apenas em um ambiente puramente na nuvem presumem, com razão, que a MFA para webmail é simplesmente como o Exchange funciona.

O Exchange local e híbrido não herdam esse comportamento. A própria pilha de autenticação do Exchange Server — a função de Serviços de Acesso do Cliente, responsável pelo OWA e pelo Centro de Administração do Exchange — valida um nome de usuário e uma senha no Active Directory e, na ausência de configuração adicional, essa é toda a decisão de autenticação. Não há um segundo fator nativo integrado ao login do OWA local. As implantações híbridas complicam ainda mais a situação: algumas caixas de correio podem já ter sido migradas para o Exchange Online e estar cobertas pelo Acesso Condicional, enquanto outras permanecem no local e ainda podem depender do próprio caminho de autenticação do Exchange Server, a menos que a Autenticação Moderna Híbrida ou outra solução de MFA tenha sido explicitamente configurada. É perfeitamente possível que uma organização acredite que seu e-mail está “protegido por MFA” porque isso é verdade para o locatário, enquanto um subconjunto significativo de caixas de correio ainda está protegido apenas por senha no OWA local.

Essa é a lacuna que importa operacionalmente, não porque o Exchange local seja inerentemente menos seguro por padrão, mas porque coloca a responsabilidade de adicionar um segundo fator de autenticação diretamente sobre o administrador do Exchange, sem nenhuma configuração padrão à qual recorrer.

O que uma conta comprometida do OWA ou do EAC realmente oferece a um invasor

É fácil subestimar o valor de uma única credencial do OWA se você pensar nela como “apenas e-mail”. Na prática, uma conta de caixa de correio comprometida é um ponto de entrada com várias rotas de ataque distintas que se ramificam a partir dela.

O comprometimento de e-mail corporativo (BEC) é o que traz o impacto financeiro mais direto.

O Business Email Compromise (BEC) é o mais direto em termos financeiros. O Centro de Denúncias de Crimes na Internet do FBI registrou US$ 3,046 bilhões em perdas relatadas por BEC nos Estados Unidos em 2025, a segunda maior categoria de perdas atrás apenas da fraude de investimentos, distribuídas por aproximadamente 24.768 denúncias — uma perda média superior a US$ 120.000 por incidente confirmado. Os ataques de BEC caracteristicamente não envolvem malware nem links maliciosos que possam ser detectados por um filtro de segurança; o invasor está dentro de uma caixa de correio legítima, enviando mensagens a partir de um endereço legítimo, muitas vezes respondendo dentro de uma conversa existente com um número de roteamento bancário modificado ou uma fatura redirecionada. As regras de fluxo de e-mails tornam a técnica mais difícil de ser detectada após o fato — um invasor com acesso à caixa de correio pode criar uma regra na caixa de entrada que encaminha ou exclui silenciosamente mensagens contendo palavras como “fatura”, “transferência” ou “pagamento”, mantendo a invasão invisível para o titular da conta enquanto a conversa fraudulenta continua em paralelo.

O acesso delegado agrava a exposição.

O acesso delegado agrava a exposição. Assistentes executivos e membros da equipe financeira frequentemente possuem permissões de delegado ou “enviar como” nas caixas de correio dos executivos como parte do fluxo de trabalho normal, o que significa que uma única conta de assistente comprometida pode ser usada para enviar comunicações que parecem ter origem diretamente de um diretor financeiro ou CEO, sem nunca acessar as credenciais do próprio executivo.

A exposição de dados é o risco mais silencioso

A exposição de dados é o risco mais silencioso e, muitas vezes, o mais grave para organizações regulamentadas. Uma caixa de correio acumula anos de anexos, memorandos internos, correspondência de RH e comunicações com clientes, todos acessíveis por meio da própria interface do OWA assim que um invasor é autenticado — sem a necessidade de ferramentas separadas de exfiltração, pois o invasor pode acessar e baixar o conteúdo da caixa de correio usando a funcionalidade legítima do OWA.

Abordagem 1: MFA aplicada diretamente ao login no OWA e no EAC

A correção mais direcionada aborda a superfície específica em risco sem afetar nada mais conectado ao Active Directory. A MFA para o Outlook Web App e o Exchange Admin Center é instalada como um componente na função de serviços de Acesso de Cliente do Exchange, posicionando-se à frente das páginas de login existentes do OWA e do EAC, em vez de substituir completamente o mecanismo de autenticação do Exchange. Uma vez instalado, os usuários primeiro se autenticam com seu nome de usuário e senha normais do AD e, em seguida, concluem uma segunda etapa de autenticação — por exemplo, inserindo uma OTP de um aplicativo autenticador ou token de hardware, ou aprovando uma notificação push — antes que a sessão seja concedida.

O escopo é definido por meio da associação a grupos do Active Directory no momento da instalação: um administrador pode exigir a MFA para toda a base de usuários imediatamente ou habilitá-la inicialmente para um único grupo do AD — um grupo piloto ou, especificamente, o grupo com acesso ao Centro de Administração do Exchange — enquanto a implantação mais ampla é planejada. Essa distinção é importante na prática, pois as contas do EAC representam um risco organizacional consideravelmente maior do que uma caixa de correio individual; uma conta de administrador com acesso ao EAC pode criar regras de fluxo de e-mails, modificar permissões ou exportar dados em todo o ambiente do Exchange, e é exatamente por isso que proteger os logins no EAC tende a ser a prioridade, mesmo quando a implantação completa para todos os usuários leva mais tempo.

O comportamento da sessão é configurável, e não fixo. Os administradores definem com que frequência os usuários são solicitados a inserir uma nova OTP — por exemplo, uma vez a cada 12 horas de uso contínuo do OWA —, equilibrando o incômodo da autenticação repetida com o risco de uma sessão de longa duração e sem supervisão em um dispositivo compartilhado ou não gerenciado. O componente suporta HOTP, TOTP e o OCRA de desafio-resposta, oferecendo flexibilidade para organizações que utilizam diferentes tipos de tokens OTP.

Abordagem 2: MFA no nível do Active Directory, abrangendo o OWA junto com todos os outros serviços

Uma pergunta mais específica que vale a pena fazer antes de implantar o componente específico para o OWA: o OWA é realmente o único serviço conectado ao AD que ainda realiza a autenticação apenas por senha? Para a maioria dos ambientes locais, a resposta honesta é não — o Winlogon, o RDP e, frequentemente, aplicativos internos vinculados ao LDAP encontram-se na mesma situação, protegidos apenas pela política de senhas imposta pelo AD.

A autenticação multifatorial no nível do diretório resolve essa exposição mais ampla por meio da integração diretamente no próprio Active Directory, em vez de na página de login de cada serviço individual. Em vez de uma série de implantações separadas de MFA — um componente para o OWA, um agente diferente para o RDP, um proxy RADIUS para VPN, cada um instalado, configurado e mantido de forma independente —, uma integração no nível do diretório altera a forma como as credenciais do usuário funcionam no Active Directory, substituindo senhas estáticas por senhas dinâmicas baseadas no tempo; assim, os serviços conectados ao AD podem usar as mesmas credenciais dinâmicas sem a necessidade de componentes de MFA separados para cada serviço. O OWA é abrangido não porque tenha sido especificamente visado, mas porque, assim como tudo o mais direcionado ao AD, agora precisa atender à mesma verificação de credenciais dinâmicas.

A contrapartida segue na direção oposta à da Abordagem 1: cobertura mais ampla em troca de uma mudança de maior alcance no comportamento da autenticação do AD em todo o ambiente, o que normalmente exige testes mais cuidadosos e uma implantação em etapas do que um componente OWA de serviço único. A escolha certa entre as duas depende, na verdade, do escopo — uma organização cuja única superfície conectada ao AD sem proteção seja o OWA não precisa mexer no diretório para corrigir isso; uma organização que descubra que o OWA, o RDP e o Winlogon utilizam autenticação apenas por senha tem um problema mais amplo que uma correção de serviço único não resolverá.

Como funciona o mecanismo no nível do diretório sem agentes de endpoint

Vale a pena compreender o mecanismo por trás da MFA no nível do diretório em seus próprios termos, pois ele explica por que alcança todos os serviços conectados ao AD sem instalar nada em estações de trabalho ou servidores individuais.

A Autenticação por Senha Forte Dinâmica funciona modificando a senha armazenada no próprio Active Directory, em vez de interceptar o tráfego de autenticação em cada terminal. A senha estática de um usuário é substituída por uma senha dinâmica baseada em TOTP que muda automaticamente em um intervalo configurado pelo administrador — um valor que deve ser um múltiplo de 30 segundos. A senha dinâmica atual é gerada usando o algoritmo TOTP e fica disponível para o usuário por meio do aplicativo Protectimus SMART ou de um chatbot compatível. Como a alteração ocorre diretamente no diretório, qualquer cliente ou serviço que se autentique no AD — Winlogon, RDP, OWA, aplicativos vinculados ao LDAP — usa automaticamente a senha dinâmica atual, sem que esse serviço precise saber que algo mudou.

É isso que torna a abordagem “sem agente” no sentido que importa: não há nenhum software em execução no laptop, no host RDP ou no servidor de acesso de clientes do Exchange verificando um segundo fator. O próprio diretório é o ponto de aplicação. A contrapartida correspondente é que esse componente é executado como parte de uma implantação local, em vez de um serviço exclusivamente na nuvem, uma vez que requer integração direta com o controlador de domínio.

Escolhendo o escopo: apenas webmail ou todo o ambiente do AD

Ambas as abordagens resolvem o problema subjacente — uma senha por si só não é mais suficiente para autenticar —, mas o fazem em pontos diferentes da pilha, e a escolha certa depende de um inventário honesto, e não de uma preferência padrão.

Se o OWA e o EAC forem realmente os únicos serviços que ainda realizam autenticação no AD usando apenas uma senha — a VPN já está coberta pelo RADIUS, o RDP já está bloqueado e nenhum outro aplicativo legado confia silenciosamente nas credenciais do AD —, o componente OWA direcionado preenche essa lacuna específica com o mínimo de interrupção para qualquer outro serviço em execução no diretório. Se o levantamento revelar mais de um serviço exposto — o que é mais comum quando as equipes de TI realmente começam a procurar —, a autenticação multifatorial (MFA) no nível do diretório protege todos eles a partir de um único ponto de integração, em vez de acumular um produto de MFA separado para cada um.

De qualquer forma, os números de prejuízos do FBI relacionados ao BEC apontam para o mesmo fato subjacente: um login apenas com senha em uma caixa de correio corporativa, exposta na internet aberta, não é mais uma posição defensável para qualquer organização que utilize o Exchange — seja no local, em ambiente híbrido ou de qualquer outra forma.