Técnica usa arquivos do Office e conexões ODBC para induzir o cliente a autenticar em servidor controlado por atacante por portas como 80/tcp, contornando bloqueios tradicionais de 139/tcp e 445/tcp.
| Componente | Recurso de tabelas vinculadas do Microsoft Access, com conexão ODBC para SQL Server e autenticação Windows via NTLMSSP encapsulado em TDS. |
| Vetor | Arquivo .accdb ou .mdb aberto pela vítima, ou objeto OLE em arquivo Office mais comum como .rtf, fazendo o Access iniciar conexão com servidor remoto definido no arquivo. |
| Impacto | Exposição condicionada de resposta net-NTLMv2 para servidor controlado por atacante e possibilidade de relay contra servidor NTLM interno, sem exigir saída por 139/tcp ou 445/tcp. |
| Prioridade | Aplicar versões do Office/Access com aviso de segurança, bloquear respostas NTLM para destinos não confiáveis e tratar arquivos Access recebidos de origem externa como risco de autenticação forçada. |
| Versões | A técnica foi reproduzida em ambientes padrão Windows com Office, incluindo Windows 10/11 e Office 2021 antes da mitigação observada. |
| Mitigação | Office 2021 Current Channel versão 2306 build 16529.20182 já exibia aviso em teste de 17 de julho de 2023; Microsoft Access versão 2402 build 17328.20142 teve a mitigação confirmada. |
Uma técnica de autenticação forçada explora o recurso de tabelas vinculadas do Microsoft Access para fazer o cliente Windows iniciar uma autenticação NTLM contra um servidor controlado por atacante. O mecanismo abusado é legítimo: o Access permite que uma base local mantenha referência a uma tabela externa, normalmente hospedada em SQL Server, usando ODBC. Quando o usuário acessa a tabela vinculada, o aplicativo estabelece conexão com o servidor remoto e pode tentar autenticar com a identidade Windows do próprio usuário. Em um uso normal, isso simplifica o acesso corporativo a dados centralizados; no abuso descrito, o destino remoto é escolhido pelo operador malicioso e pode estar exposto em uma porta permitida pelo perímetro, como 80/tcp.
O ponto relevante para defesa é que o fluxo não depende das portas clássicas associadas a SMB e NTLM externo, como 139/tcp e 445/tcp. Muitas organizações reduzem o risco de roubo ou relay de NTLM bloqueando essas saídas para a internet. A técnica com Access desloca a autenticação para um caminho ODBC/TDS, permitindo que a tentativa de autenticação ocorra por outra porta TCP. O resultado observado é o vazamento de uma resposta net-NTLMv2 para um servidor fora da organização, desde que a vítima abra o arquivo preparado e o Access acione a tabela vinculada. Esse material não equivale diretamente à senha em texto claro, mas pode ser usado em cenários de relay quando as condições do ambiente interno permitem completar a autenticação contra um serviço-alvo.
A cadeia começa com um arquivo de banco de dados do Access contendo uma tabela vinculada a um suposto SQL Server remoto. O arquivo pode ser .accdb ou .mdb, e o servidor definido na configuração da conexão não precisa usar a porta padrão 1433/tcp. A configuração permite informar endereço, porta e protocolo para o servidor de destino. Se o operador malicioso controla esse destino, ele recebe a conexão iniciada pelo cliente e pode conduzir o diálogo de autenticação. O detalhe técnico importante é que a autenticação ocorre como NTLMSSP encapsulado em TDS, o protocolo usado no caminho de comunicação com SQL Server. Isso cria uma rota diferente daquela que controles focados apenas em SMB costumam observar.
O ataque de relay depende de sincronizar dois diálogos de autenticação. O servidor controlado pelo atacante recebe a tentativa do cliente vítima e, em paralelo, inicia uma autenticação contra um servidor NTLM escolhido dentro da organização. O desafio emitido pelo servidor interno é repassado para o cliente vítima dentro da sessão controlada pelo atacante. Quando o cliente responde corretamente ao desafio, a resposta pode ser encaminhada ao servidor interno. O sucesso final depende de fatores do ambiente, como aceitação de NTLM pelo serviço interno, ausência de proteções que impeçam relay e contexto de autorização da conta da vítima. Portanto, o impacto confirmado é a exposição da resposta NTLM e o risco condicionado de relay, não uma execução automática de código nem comprometimento garantido.
O acionamento pode ocorrer de forma mais discreta porque o Access possui macros simples capazes de abrir a tabela vinculada quando o arquivo é aberto. Essas macros não são equivalentes a VBA completo e, no comportamento descrito, não receberam o mesmo tratamento de alerta aplicado a macros mais poderosas. Além disso, o Access é registrado no Windows como servidor de vinculação OLE. Isso permite que outro documento Office referencie um arquivo Access como objeto OLE, levando o sistema a baixar e entregar esse conteúdo ao Access. Em termos defensivos, isso amplia a superfície: o usuário pode não receber apenas um banco Access explícito, mas também um arquivo Office mais comum que provoque o processamento do objeto vinculado.
A superfície principal envolve estáções Windows com Microsoft Office e Microsoft Access instalado ou disponível para manipular objetos vinculados. O risco é maior onde usuários conseguem abrir anexos ou documentos obtidos fora do fluxo corporativo controlado e onde a saída HTTP ou outra porta TCP genérica é permitida para a internet. Ambientes que bloquearam somente 139/tcp e 445/tcp continuam protegidos contra parte dos fluxos tradicionais de autenticação NTLM para fora, mas não necessariamente contra uma autenticação encapsulada em TDS usando uma porta permitida. A técnica foi reproduzida em ambientes padrão Windows e Office, incluindo combinações com Windows 10/11 e Office 2021 antes da mitigação observada.
A mitigação introduzida pela Microsoft adiciona uma barreira de decisão para o usuário quando o Access tenta processar esse caminho. Em teste com Office 2021 Current Channel versão 2306 build 16529.20182, realizado em 17 de julho de 2023, o comportamento já exibia uma caixa de aviso. A confirmação posterior também abrange Microsoft Access versão 2402 build 17328.20142. Como o primeiro build exato que recebeu a alteração não foi definido, equipes devem validar a postura real em seus canais de atualização, especialmente em instalações com atualização diferida, ambientes VDI, imagens antigas de estáção e pacotes Office mantidos por compatibilidade.
- Estáções Windows com Microsoft Access capaz de abrir
.accdb,.mdbou objetos OLE que apontem para banco Access. - Controles de saída que bloqueiam SMB externo, mas permitem conexões TCP genéricas, como 80/tcp, para destinos fora da organização.
- Serviços internos que ainda aceitam NTLM e não aplicam proteções suficientes contra relay de autenticação.
A investigação deve correlacionar abertura de documentos Office com conexões de rede incomuns originadas do processo do Access ou de processos Office que acionem OLE. O sinal mais útil é a tentativa de conexão para endereço externo em porta não esperada para SQL Server, seguida de negociação compatível com TDS e autenticação NTLM. Como o servidor malicioso pode escutar em 80/tcp, o tráfego pode parecer HTTP apenas pelo número da porta; a inspeção de protocolo, quando disponível, deve diferenciar conexão TDS de navegação web comum. Em endpoints, a sequência temporal de abertura de arquivo, inicialização do Access e saída para destino externo ajuda a separar uso legítimo de banco vinculado de tentativa de autenticação forçada.
Em ambientes com EDR, proxies e firewall com metadados de processo, vale procurar conexões iniciadas por MSACCESS.EXE para endereços públicos, principalmente quando a porta não é 1433/tcp ou quando o destino não faz parte de inventário de fornecedores autorizados. Em logs de identidade, a defesa deve procurar autenticações NTLM anômalas contra serviços internos imediatamente após a estáção contatar um destino externo suspeito. O objetivo não é publicar ou depender de uma lista extensa de indicadores, mas identificar o padrão comportamental: documento recebido, processamento pelo Office, conexão ODBC/TDS inesperada, resposta NTLM emitida e possível tentativa de uso contra serviço interno.
Também é útil verificar controles de macro e eventos relacionados a documentos que contenham objetos OLE. Mesmo quando a macro simples do Access não gera o mesmo alerta de VBA, a telemetria de criação ou abertura de objeto vinculado pode indicar exploração. Gateways de e-mail e soluções de sandbox devem tratar arquivos Access e documentos Office com referências OLE externas como anexos de maior risco. A ausência de payload executável tradicional não reduz a severidade: a finalidade da cadeia é autenticação forçada, e o artefato principal é o segredo derivado da sessão NTLM, não um binário malicioso implantado no disco.
- Conexões de
MSACCESS.EXEpara endereços externos em portas incomuns ou permitidas genericamente, incluindo 80/tcp. - Negociação TDS com autenticação NTLM para destino que não pertence ao inventário de bancos corporativos.
- Abertura de
.accdb,.mdb,.rtfou outro documento Office seguida de tráfego externo imediato. - Autenticações NTLM internas próximas no tempo a uma conexão externa suspeita feita pela mesma estáção.
A resposta deve começar pela atualização do Office e do Access para builds que exibem aviso antes do processamento perigoso. Como a mitigação foi confirmada no Access versão 2402 build 17328.20142 e já havia sido observada no Office 2021 Current Channel versão 2306 build 16529.20182, equipes precisam comparar esses marcos com o canal efetivamente instalado. Em parques com atualização semiautomatizada, a checagem deve incluir máquinas fora de domínio, hosts de suporte, VDI persistente e imagens usadas para provisionamento. A decisão do usuário diante do aviso também deve ser coberta por orientação corporativa: arquivos Access de origem não confiável não devem ser autorizados a iniciar conexões externas.
No perímetro e no endpoint, a mitigação mais robusta é reduzir NTLM onde possível e restringir autenticação NTLM para destinos não confiáveis. Bloquear 139/tcp e 445/tcp continua sendo uma medida válida, mas não deve ser tratado como controle completo contra autenticação forçada. Políticas de firewall devem considerar o processo de origem, o protocolo real e a lista de destinos permitidos para bancos SQL. Quando o Access não for necessário para usuários finais, a remoção do componente ou o bloqueio de tipos de arquivo associados reduz a superfície. Onde o Access for necessário, conexões ODBC devem ser governadas por inventário, destinos aprovados e monitoramento.
Para contenção após suspeita de exploração, a equipe deve preservar o arquivo recebido, registrar o destino externo contatado de forma defangada, revisar a conta do usuário afetado e procurar tentativas de autenticação NTLM contra serviços internos no mesmo intervalo. Se houver indício de relay bem-sucedido, a resposta deve abranger logs do serviço-alvo, sessões criadas, alterações de permissão e uso da conta da vítima. A rotação de senha pode ser necessária quando houver risco de captura e uso posterior do material NTLM, mas não substitui o bloqueio do vetor. A validação final deve confirmar que documentos Access externos não conseguem iniciar autenticação silenciosa sem aviso e que conexões TDS externas não autorizadas são bloqueadas ou alertadas.
- Atualizar Microsoft Office e Access e validar se o aviso de segurança aparece ao abrir arquivos Access não confiáveis com tabelas vinculadas.
- Restringir NTLM para destinos externos e reduzir dependência de NTLM em serviços internos que possam ser alvo de relay.
- Criar regra de detecção para
MSACCESS.EXEiniciando conexões externas não autorizadas, especialmente em 80/tcp ou portas fora do inventário SQL. - Bloquear ou isolar anexos
.accdb,.mdbe documentos Office com objetos OLE externos quando não houver necessidade de negócio. - Revisar autenticações NTLM internas após eventos de abertura de documentos suspeitos e tratar correlação positiva como possível tentativa de relay.
0 Comentários