Atacantes abusaram do Microsoft Power BI para distribuir clientes não autorizados do ScreenConnect, software de monitoramento e gerenciamento remoto (RMM), usando a infraestrutura confiável da Microsoft para disfarçar links de phishing e estabelecer acesso persistente.
A Huntress observou a campanha a partir de 10 de setembro de 2026 em diversos endpoints.
Uma busca retrospectiva vinculou uma configuração distinta de cliente ScreenConnect a 22 endpoints adicionais em incidentes separados, sem confirmar que todos pertenciam a esta campanha de phishing.
A operação combinou iscas em painéis públicos, fingerprinting de navegador, downloads atrasados de executáveis e instalações redundantes de acesso remoto.
A Huntress observou posteriormente um utilitário de ocultação e uma tarefa automatizada de reparo, demonstrando como um software legítimo de administração remota pode se tornar um mecanismo de persistência para os atacantes.
A invasão começou com um e-mail de phishing no Outlook contendo um link para um falso documento de referência hospedado em app.powerbi.com.
A Huntress não conseguiu recuperar a mensagem original nem sua isca específica. A página de destino exibia um formulário borrado e instruía os destinatários a clicar em "Download Reference" (Baixar Referência), movendo-os do domínio legítimo da Microsoft para uma infraestrutura controlada pelos atacantes.
De acordo com a investigação da Huntress, os atacantes podem publicar painéis do Power BI publicamente acessíveis contendo links maliciosos de saída.
Isso explora a reputação de um serviço de nuvem legítimo, em vez de uma vulnerabilidade documentada no software Power BI, e pode contornar controles de e-mail que confiam em URLs hospedadas pela Microsoft.
Phishing via Power BI
Clicar no botão de download abria dailylifeproject[.]site/S/. Outros domínios de entrega observados incluíam burnsworth[.]site, essaywritingservice[.]site e openpediatrics[.]site.
Essas páginas inspecionavam versões de navegador, sistemas operacionais, características do dispositivo, indicadores de automação, dimensões de tela, contexto de iframe e cookies associados a provedores de nuvem antes de permitir a entrega. Visitantes que não passavam nas verificações eram redirecionados para check.vykyn[.]click/E/.
As páginas de destino também incorporavam uma credencial da API de Bots do Telegram e um identificador de chat para transmitir telemetria das vítimas, incluindo endereços IP, geolocalização, detalhes do navegador e atividade de download.
Uma variante restringia o acesso a desktops Windows enquanto filtrava provedores de internet associados à Microsoft ou desconhecidos, ajudando a excluir scanners e ambientes de análise.
Em vez de fornecer o payload imediatamente, os scripts da página aguardavam alguns segundos antes de ativar programaticamente um link de download oculto.
Uma notificação então afirmava que um "Reference Verification Form" (Formulário de Verificação de Referência) havia sido baixado com sucesso, incentivando as vítimas a inspecionar a pasta de Downloads.
O arquivo baixado era um instalador do ScreenConnect, e não um documento de referência.
O instalador era proveniente de hamham27[.]screenconnect[.]com. Variantes da campanha reutilizavam esse tenant e o caminho do instalador, alterando os parâmetros de acesso de convidados, incluindo ILEAYEASAN, PERFECTO e PAPASUPE.
O primeiro cliente não autorizado, 2b302081e9e777d0, conectou-se a instance-g01s1n-relay[.]screenconnect[.]com e estabeleceu um segundo cliente, 43773b3da4ccb17b, associado a onthegotree[.]site.
Em um incidente, LyN03DvVjUKPrun.cmd executou SCAutoFix.ps1 a partir de um diretório temporário.
O script PowerShell baixou outro instalador do ScreenConnect e removeu a instância inicial, o que a Huntress avaliou como provável evasão de detecção.
Os atacantes também executaram HideUL_x64.exe, avaliado como uma ferramenta para ocultar atividades, e criaram SCAutoRepairEvery2Min para executar o script a cada dois minutos. O SOC (Centro de Operações de Segurança) da Huntress interrompeu o ataque nessa etapa.
A redundância se assemelha a investigações anteriores da Huntress sobre phishing browser-in-the-browser, em que prompts falsos do Adobe Reader distribuíam múltiplos clientes ScreenConnect e binários de ocultação.
Técnicas semelhantes não estabelecem atribuição compartilhada, mas reforçam o valor operacional que os atacantes atribuem à manutenção de caminhos alternativos de acesso remoto.
Os defensores devem investigar instalações inesperadas do ScreenConnect, conexões de relay não autorizadas, scripts de acesso remoto e tarefas agendadas recorrentes.
A remediação deve identificar todos os clientes instalados e os mecanismos de persistência associados; remover apenas a primeira instância visível pode deixar outro ponto de apoio operacional intacto em sistemas comprometidos.
Indicadores de Compromisso
Nota: Endereços IP e domínios estão intencionalmente desativados (por exemplo, [.]) para evitar resolução ou criação de hiperlink acidental. Reative-os apenas em plataformas controladas de inteligência de ameaças, como MISP, VirusTotal ou seu SIEM (Sistema de Gerenciamento de Eventos e Informações de Segurança).
Interrompa ameaças cibernéticas antes do impacto com MTTR (Tempo Médio de Resposta) 21 minutos mais rápido. Integre o Sandbox da ANYRUN ao seu SOC.
