Como Hackers Contornaram o 2FA e Invadiram a Infraestrutura de Nuvem
Este artigo detalha um caso real de como atacantes conseguiram acesso não autorizado a uma infraestrutura de nuvem, explorando a técnica Shadow RDP para assumir sessões de administradores já autenticados, mesmo com a autenticação de dois fatores (2FA) habilitada. A análise forense e as medidas de proteção são cruciais para mitigar esse tipo de ataque.
MundiX News·13 de abril de 2026·7 min de leitura·👁 10 views
Como Hackers Contornaram o 2FA e Invadiram a Infraestrutura de Nuvem
Introdução
Nos últimos anos, a infraestrutura híbrida se tornou o padrão de facto. Empresas estão migrando serviços críticos para Azure, AWS, Google Cloud ou Yandex.Cloud, mas mantêm o Active Directory (AD) on-premise como ponto de confiança. Quase sempre, a autenticação multifator (MFA) está habilitada para acesso às contas administrativas da nuvem, vista como uma barreira intransponível.
Neste artigo, analisaremos um caso prático de investigação onde os invasores não precisaram quebrar o 2FA. Em vez disso, encontraram uma maneira de entrar legalmente na nuvem sob a sessão de um administrador já autorizado. A técnica é chamada de Shadow RDP.
Condições Iniciais
Configuração híbrida: AD on-premise + Azure AD Connect
Dados críticos no Azure: VM, Storage
MFA habilitado para todas as contas privilegiadas
Etapas do Ataque
Os atacantes comprometeram uma conta de administrador no Active Directory local (on-premise). Em vez de tentar acessar diretamente os recursos da nuvem, eles exploraram uma funcionalidade legítima do Windows chamada Shadow RDP para controlar a sessão de um administrador já autenticado no Azure.
Por que os logs do Azure AD não ajudaram imediatamente?
O Azure AD registrou um único login bem-sucedido com MFA pela manhã. Todas as ações subsequentes pareceram ser uma continuação da mesma sessão. A anomalia foi detectada apenas ao analisar a duração da sessão, que excedeu 12 horas, embora o administrador não trabalhasse durante a noite.
Detalhes Técnicos do Shadow RDP
Shadow RDP é um recurso nativo do Windows 10/11 ou Windows Server com a função Remote Desktop Services Host (RDSH): um usuário se conecta à sessão ativa de outro.
O que os hackers mudaram na máquina do administrador?
Configuraram o modo de conexão shadow:
# controle total da sessão sem solicitar consentimento (modo 2)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /t REG_DWORD /d 2 /f
# Desativar a notificação do usuário sobre a observação (opcional)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v ShadowNotification /t REG_DWORD /d 0 /f
Modos de Shadow (valores):
0 - Proibido
1 - Controle total com permissão
2 - Controle total sem permissão
3 - Observação com permissão
4 - Observação sem permissão (usado no ataque)
Configuraram regras do Windows Defender Firewall
Quais eventos podem ser monitorados nos logs do Windows:
| Fonte | Event ID | O que registra | | Security (estação do admin) | 4657 | Mudança de Shadow / ShadowNotification no registro WITH THE POWER OF AI, WE CAN DO IT FASTER. ## Medidas de Proteção
Para mitigar ataques como este, considere as seguintes medidas de proteção:
Desativar o Shadow RDP onde não for necessário (GPO).
Forçar o encerramento das sessões RDP (GPO).
"Limitar a duração da sessão dos serviços de área de trabalho remota" → por exemplo, 8 horas
"Encerrar a sessão quando o limite for atingido" → Ativado
Acesso Condicional no Azure AD.
Política de "Frequência de verificação de autenticação": MFA recorrente a cada 1-2 horas.
Política de "Exigir reautenticação ao mudar de IP".
Proibir "Manter-me conectado" para funções privilegiadas.
Proteção dos próprios hosts RDP.
Ativar o Restricted Admin Mode (impede a transmissão de credenciais).
Ativar o Credential Guard.
Usar o Remote Credential Guard para conexões.
Estações de trabalho privilegiadas (PAW / PAM).
Estações separadas e limpas para gerenciamento da nuvem.
Reinicialização forçada após cada sessão.
Proibir o acesso à internet (exceto à nuvem) e e-mail a partir da PAW.
Monitoramento (SIEM / SOAR).
Detectar alterações no registro.
Detectar Event ID 20503 / 20504.
Correlacionar eventos da nuvem e on-premise.
Unificar logs da nuvem e on-premise.
Conclusão
O MFA é um elemento de segurança obrigatório, mas insuficiente. Uma sessão após um login bem-sucedido é um novo perímetro de ataque. Se você não controlar quem está por trás do teclado na sessão, quanto tempo a sessão dura e quais processos são executados na estação do administrador, o MFA não o salvará de um ataque Shadow RDP ou técnicas similares de session hijacking.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Como Hackers Contornaram o 2FA e Invadiram a Infraestrutura de Nuvem
Introdução
Nos últimos anos, a infraestrutura híbrida se tornou o padrão de facto. Empresas estão migrando serviços críticos para Azure, AWS, Google Cloud ou Yandex.Cloud, mas mantêm o Active Directory (AD) on-premise como ponto de confiança. Quase sempre, a autenticação multifator (MFA) está habilitada para acesso às contas administrativas da nuvem, vista como uma barreira intransponível.
Neste artigo, analisaremos um caso prático de investigação onde os invasores não precisaram quebrar o 2FA. Em vez disso, encontraram uma maneira de entrar legalmente na nuvem sob a sessão de um administrador já autorizado. A técnica é chamada de Shadow RDP.
Condições Iniciais
Configuração híbrida: AD on-premise + Azure AD Connect
Dados críticos no Azure: VM, Storage
MFA habilitado para todas as contas privilegiadas
Etapas do Ataque
Os atacantes comprometeram uma conta de administrador no Active Directory local (on-premise). Em vez de tentar acessar diretamente os recursos da nuvem, eles exploraram uma funcionalidade legítima do Windows chamada Shadow RDP para controlar a sessão de um administrador já autenticado no Azure.
Por que os logs do Azure AD não ajudaram imediatamente?
O Azure AD registrou um único login bem-sucedido com MFA pela manhã. Todas as ações subsequentes pareceram ser uma continuação da mesma sessão. A anomalia foi detectada apenas ao analisar a duração da sessão, que excedeu 12 horas, embora o administrador não trabalhasse durante a noite.
Detalhes Técnicos do Shadow RDP
Shadow RDP é um recurso nativo do Windows 10/11 ou Windows Server com a função Remote Desktop Services Host (RDSH): um usuário se conecta à sessão ativa de outro.
O que os hackers mudaram na máquina do administrador?
Configuraram o modo de conexão shadow:
# controle total da sessão sem solicitar consentimento (modo 2)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /t REG_DWORD /d 2 /f
# Desativar a notificação do usuário sobre a observação (opcional)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v ShadowNotification /t REG_DWORD /d 0 /f
Modos de Shadow (valores):
0 - Proibido
1 - Controle total com permissão
2 - Controle total sem permissão
3 - Observação com permissão
4 - Observação sem permissão (usado no ataque)
Configuraram regras do Windows Defender Firewall
Quais eventos podem ser monitorados nos logs do Windows:
| Fonte | Event ID | O que registra | | Security (estação do admin) | 4657 | Mudança de Shadow / ShadowNotification no registro WITH THE POWER OF AI, WE CAN DO IT FASTER. ## Medidas de Proteção
Para mitigar ataques como este, considere as seguintes medidas de proteção:
Desativar o Shadow RDP onde não for necessário (GPO).
Forçar o encerramento das sessões RDP (GPO).
"Limitar a duração da sessão dos serviços de área de trabalho remota" → por exemplo, 8 horas
"Encerrar a sessão quando o limite for atingido" → Ativado
Acesso Condicional no Azure AD.
Política de "Frequência de verificação de autenticação": MFA recorrente a cada 1-2 horas.
Política de "Exigir reautenticação ao mudar de IP".
Proibir "Manter-me conectado" para funções privilegiadas.
Proteção dos próprios hosts RDP.
Ativar o Restricted Admin Mode (impede a transmissão de credenciais).
Ativar o Credential Guard.
Usar o Remote Credential Guard para conexões.
Estações de trabalho privilegiadas (PAW / PAM).
Estações separadas e limpas para gerenciamento da nuvem.
Reinicialização forçada após cada sessão.
Proibir o acesso à internet (exceto à nuvem) e e-mail a partir da PAW.
Monitoramento (SIEM / SOAR).
Detectar alterações no registro.
Detectar Event ID 20503 / 20504.
Correlacionar eventos da nuvem e on-premise.
Unificar logs da nuvem e on-premise.
Conclusão
O MFA é um elemento de segurança obrigatório, mas insuficiente. Uma sessão após um login bem-sucedido é um novo perímetro de ataque. Se você não controlar quem está por trás do teclado na sessão, quanto tempo a sessão dura e quais processos são executados na estação do administrador, o MFA não o salvará de um ataque Shadow RDP ou técnicas similares de session hijacking.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
