ACR Stealer e Infostealers: Detetar, Prevenir e Responder em PME

Os infostealers tornaram-se numa das ameaças mais prolíficas para PMEs em 2026. Diferente do ransomware que encripta e pede resgate, um infostealer rouba silenciosamente credenciais, cookies de sessão e ficheiros sensíveis — muitas vezes sem que a vítima perceba que foi comprometida. O ACR Stealer, analisado em detalhe pelo Microsoft Security Blog em Julho 2026, representa a nova geração desta categoria: usa técnicas ClickFix, WebDAV, esteganografia e até blockchain para evadir detecção. Este guia técnico mostra como detectar, prevenir e responder a infostealers em redes Windows com Microsoft Defender for Endpoint.

1. O Que São Infostealers (e Como Diferem de Ransomware)

Infostealers são uma categoria de malware desenhada especificamente para extrair dados valiosos do endpoint comprometido: credenciais guardadas em browsers, cookies de sessão, tokens de autenticação, ficheiros de documentos (PDFs, Office) e dados sincronizados com serviços cloud como OneDrive e SharePoint. O objetivo não é destruir dados — é recolher informação que permita acesso subsequente a sistemas corporativos, contas bancárias, redes sociais e serviços SaaS.

O ACR Stealer, em particular, é oferecido segundo um modelo de Malware-as-a-Service (MaaS) e está associado ao rebranding de uma família anterior chamada Amatera Stealer. Isto significa que actores de ameaça diferentes podem alugar a infraestrutura e personalizar campanhas, tornando a detecção mais complexa — o mesmo malware pode chegar por vectors completamente diferentes consoante o operador.

Infostealer vs Ransomware: Comparação Técnica

A confusão entre infostealers e ransomware é comum em PMEs sem equipa de segurança dedicada. Ambos entram no endpoint por vectors semelhantes (email, software piratado, documentos maliciosos), mas os objectivos, o impacto e a resposta são radicalmente diferentes.

2. ACR Stealer: Cadeias de Intrusão Observadas

O Microsoft Security Blog documentou duas campanhas principais activas entre Abril e meados de Junho 2026, ambas observadas por Microsoft Defender Experts em ambientes de clientes. Ambas começam com a técnica ClickFix — um prompt social-engineering que engana o utilizador para executar um comando — mas divergem significativamente na entrega de payload, execução e evasão.

Campanha 1: ClickFix WebDAV com Loaders Python e C2 Blockchain

A primeira campanha usa um prompt ClickFix (provavelmente entregue via malvertising ou SEO poisoning) que instrui o utilizador a executar um comando que lança cmd.exe. O comando invoca rundll32.exe para carregar uma DLL de um share WebDAV remoto acedido via HTTPS. O caminho WebDAV usa uma estrutura de directórios baseada em GUIDs e nomes de ficheiros desenhados para parecerem recursos legítimos (ex: google.ct).

Três variantes de execução inicial foram observadas:

• Variante 1: Invocação directa de rundll32 sobre o share WebDAV
• Variante 2: Uso de pushd para mapear o share WebDAV como drive local temporário, simplificando execução
• Variante 3: Execução headless e obfuscada com conhost.exe --headless e expansão de variáveis de ambiente com delay para ocultar pushd, rundll32 e o hostname remoto

Após a DLL ser carregada, o malware estabelece comunicação com infraestrutura controlada pelo atacante e executa um script PowerShell fortemente obfuscado. Este script usa no-ops aritméticos, loops mortos, control flow falso e nomes de variáveis aleatórios para evadir análise estática. De seguida, funciona como instalador e mecanismo de persistência:

• Descarrega um payload ZIP de um servidor remoto e extrai para um directório sob %LocalAppData%\Temp (ex: LogiOptionsPlus)
• Lança um script Python com pythonw.exe para evitar janela de consola
• Cria uma scheduled task oculta disfarçada de update de software, garantindo execução no sign-in do utilizador
• Copia timestamps de notepad.exe (timestomping) e limpa o histórico de comandos PowerShell

O componente Python é um loader obfuscado que usa múltiplas camadas de defesa: resolução dinâmica de APIs, reconstrução de strings codificadas, shifting de caracteres, reversão de strings, Base64 e decompressão zlib. O payload final é um shellcode loader in-memory que usa VirtualAlloc + Windows Fiber API (ConvertThreadToFiber, CreateFiber, SwitchToFiber) para execução stealth.

Uma variação notável usa blockchain como dead-drop resolver (técnica conhecida como EtherHiding): um segundo loader Python comunica com endpoints RPC blockchain públicos para obter payloads ou endereços C2 armazenados num ledger descentralizado. Isto permite aos operadores actualizar infraestrutura sem modificar o malware, complicando takedown.

Campanha 2: MSHTA + PowerShell com Payload Esteganográfico

A segunda campanha segue uma abordagem essencialmente fileless. O ClickFix prompt despoleta mshta.exe para ir buscar e executar conteúdo HTA remoto de um domínio controlado pelo atacante. O VBScript loader embutido abusa de COM objects para descodificar e executar conteúdo PowerShell codificado.

O estágio PowerShell usa obfuscação semelhante à Campanha 1, mas em vez de descarregar um script secundário, recupera uma imagem JPEG de um serviço de image-hosting. Rotinas custom extraem um payload embutido nos pixels da imagem (esteganografia), que é depois descriptografado, decomprimido e executado totalmente em memória. O payload resolve APIs dinamicamente (LoadLibrary, GetProcAddress, VirtualAlloc, CreateThread) para shellcode reflectivo.

3. Vectors de Infecção: Como os Infostealers Chegam ao Endpoint

Compreender os vectors de infecção é o primeiro passo para fechar as portas de entrada. O ACR Stealer e infostealers em geral usam uma combinação de técnicas que exploram o factor humano mais do que vulnerabilidades técnicas.

ClickFix: O Social Engineering Principal

A técnica ClickFix é o vector inicial em ambas as campanhas ACR Stealer documentadas. Consiste num prompt falso (tipicamente um popup num website comprometido ou anúncio malicioso) que simula um erro de verificação, CAPTCHA ou alerta de sistema. O prompt pede ao utilizador para “corrigir” o problema copiando e colando um comando na consola ou executando uma instrução. O comando, naturalmente, é o payload malicioso.

O ClickFix é particularmente eficaz porque contorna as defesas tradicionais: o utilizador executa o comando manualmente, não há download de ficheiro executável, e o processo parece legítimo aos olhos do OS. Os atacantes usam malvertising (anúncios maliciosos em sites legítimos) e SEO poisoning (manipulação de resultados de busca) para fazer com que as vítimas encontrem as páginas com ClickFix.

Outros Vectors Comuns em Infostealers

4. Exfiltração de Credenciais e Browser Cookies

O coração de qualquer infostealer é a fase de coleta de dados. O ACR Stealer, como a maioria dos infostealers modernos, foca-se em três categorias principais de dados: credenciais de browser, tokens de sessão e ficheiros sensíveis. Compreender exatamente o que é roubado é essencial para dimensionar correctamente a resposta a incidente.

Roubo de Credenciais de Browser via DPAPI

Os browsers modernos (Chrome, Edge, Firefox) guardam passwords, cookies e dados de auto-fill em bases de dados SQLite locais encriptadas pela Windows Data Protection API (DPAPI). O ACR Stealer invoca rotinas DPAPI para descriptografar localmente:

• Login Data — base de dados SQLite com passwords guardadas em browsers Chromium (Chrome, Edge, Brave)
• Web Data — dados de auto-fill, cartões de crédito, endereços
• Cookies — cookies de sessão que permitem bypass de MFA em sessões já autenticadas
• Tokens de autenticação — tokens OAuth, tokens de refresh para serviços SaaS

Coleta de Ficheiros e Dados Enterprise

Para além das credenciais de browser, o ACR Stealer enumera e acede ficheiros de alto valor em todo o sistema:

• Documentos PDF no Desktop e Downloads
• Documentos Microsoft 365 (Word, Excel, PowerPoint)
• Dados sincronizados via OneDrive e SharePoint
• Ficheiros em directórios enterprise sincronizados localmente

Após a coleta, os dados são arquivados (comprimidos) e preparados para exfiltração. A compressão reduz o tamanho do payload exfiltrado e ajuda a evadir detecção baseada em volume de tráfego.

O Que o Atacante Faz com os Dados Roubados

5. Detecção com Defender for Endpoint: ASR Rules e Indicators

O Microsoft Defender for Endpoint (MDE) é a principal ferramenta de detecção e resposta para ambientes Windows PME. Para ACR Stealer e infostealers em geral, a detecção baseia-se em três pilares: Attack Surface Reduction (ASR) rules, indicators de compromisso (IOCs), e detecção comportamental com EDR em block mode.

ASR Rules Relevantes para Infostealers

As ASR rules reduzem as superfícies de ataque bloqueando comportamentos típicos de malware. Várias rules são directamente relevantes para bloquear as técnicas usadas pelo ACR Stealer:

Para activar ASR rules via PowerShell (executar como administrador no endpoint):

# Verificar ASR rules actuais
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids

# Activar ASR rules em modo Block (IDs das rules relevantes)
# Block obfuscated scripts: 5BEB7EBA-FCD3-4E1F-8F49-2F6F91C15C27
# Block executable from email: 75668C1F-73B5-4CF0-BB93-3ECF2CB89AC7
# Block Win32 API from Office: 3B576869-A4EC-4529-8536-B80A7769E899
# Block credential stealing from LSASS: 9E6C4E1F-7D60-472F-BA1A-A39EF669CE3B

Add-MpPreference -AttackSurfaceReductionRules_Ids @(
  "5BEB7EBA-FCD3-4E1F-8F49-2F6F91C15C27",
  "75668C1F-73B5-4CF0-BB93-3ECF2CB89AC7",
  "3B576869-A4EC-4529-8536-B80A7769E899",
  "9E6C4E1F-7D60-472F-BA1A-A39EF669CE3B"
) -AttackSurfaceReductionRules_Actions Block

# Verificar activação
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions

Em ambientes com Intune, as ASR rules devem ser configuradas via Endpoint security → Attack surface reduction policy, atribuídas a grupos de dispositivos. A referência completa de IDs e GUIDs está na documentação oficial de ASR rules reference.

Indicators of Compromise (IOCs) do ACR Stealer

A Microsoft publicou IOCs específicos das duas campanhas. Estes podem ser importados como indicators no Defender for Endpoint para bloqueio automático:

Para adicionar um IOC como indicator de bloqueio no Defender for Endpoint via API:

# Adicionar indicator de dominio via Graph API (PowerShell)
# Requer Microsoft Graph PowerShell SDK
Connect-MgGraph -Scopes "TiIndicators.ReadWrite.All"

$params = @{
    indicatorType = "domainName"
    indicatorValue = "looksta.icu"
    action = "block"
    title = "ACR Stealer C2 - Campanha 1"
    description = "IOC from Microsoft Security Blog 2026-07-16"
    expirationTime = (Get-Date).AddDays(90).ToString("o")
    severity = "high"
    targetProduct = "Microsoft Defender ATP"
    generateAlert = $true
}

New-MgSecurityTiIndicator -BodyParameter $params

Detecções Defender XDR Nativas

O Defender XDR tem cobertura comportamental nativa para as técnicas observadas nas duas campanhas ACR Stealer:

6. Resposta a Incidente: Isolar, Reset Passwords, Revogar Sessões

A resposta a um incidente de infostealer tem de ser rápida e completa. Ao contrário do ransomware onde o impacto é imediato e visível, um infostealer pode ter exfiltrado dados há dias ou semanas antes da detecção. A janela entre o roubo e o uso das credenciais é crítica — cada minuto conta para revogar o que foi roubado.

Passo 1: Isolar o Endpoint Comprometido

O primeiro passo é isolar o dispositivo para prevenir exfiltração adicional e lateral movement. O Defender for Endpoint permite isolar máquinas via API ou portal:

# Isolar maquina via Defender for Endpoint API (Graph API)
# Requer Microsoft Graph PowerShell SDK
Connect-MgGraph -Scopes "Machine.Isolate.All"

# Obter ID da maquina pelo nome
$machine = Get-MgSecurityMachine -Filter "computerDnsName eq 'WKS-FINANCE-01'"

# Isolar (mantem ligacao ao Defender para resposta)
$params = @{
    comment = "ACR Stealer detectado - isolamento de emergencia"
    isolationType = "Full"
}
Invoke-MgIsolateMachine -MachineId $machine.Id -BodyParameter $params

# Verificar estado de isolamento
Get-MgSecurityMachine -MachineId $machine.Id | Select-Object computerDnsName, machineActions

O isolamento Full corta todas as ligações de rede excepto a comunicação com o serviço Defender for Endpoint, permitindo continuar a recolher telemetria e executar acções de resposta. O isolamento pode também ser feito directamente no portal Defender XDR → Devices → selecionar dispositivo → Isolate device.

Passo 2: Reset de Passwords e Revogação de Sessões

Este é o passo mais crítico e frequentemente subestimado. Todas as credenciais que possam ter estado no browser comprometido devem ser consideradas comprometidas. Isto inclui:

• Passwords de contas Microsoft 365 (forçar reset via Entra ID)
• Passwords de outros serviços SaaS (CRM, contabilidade, HR)
• Passwords locais de Windows/AD se guardadas no browser
• Todas as sessões activas devem ser revogadas (tokens de refresh invalidados)

# Revogar todas as sessoes do utilizador no Entra ID (Microsoft 365)
Connect-MgGraph -Scopes "User.RevokeSessions.All", "User.ReadWrite.All"

# Revogar todas as sessoes (refresh tokens, sessao tokens)
Revoke-MgUserSignInSession -UserId "[email protected]"

# Forcar reset de password
$params = @{
    passwordProfile = @{
        forceChangePasswordNextSignIn = $true
        password = "TempP@ss2026!Change"
    }
}
Update-MgUser -UserId "[email protected]" -BodyParameter $params

# Verificar revogacao - o utilizador tera de re-autenticar
Get-MgUser -UserId "[email protected]" -Property displayName, refreshTokensValidFromDateTime

Passo 3: Investigar Persistência e Artefactos

No endpoint isolado, investigar e remover todos os mecanismos de persistência:

# No endpoint comprometido (PowerShell como admin):

# 1. Listar scheduled tasks suspeitas (procurar nomes de "update")
Get-ScheduledTask | Where-Object {
    $_.State -ne "Disabled" -and
    $_.TaskName -match "update|autoupdate|logi|software"
} | Format-Table TaskName, State, Author -AutoSize

# 2. Verificar directórios Temp suspeitos
Get-ChildItem "$env:LOCALAPPDATA\Temp" -Directory |
  Where-Object { $_.Name -match "Logi|Options|Plus" } |
  Select-Object Name, CreationTime, LastWriteTime

# 3. Verificar historico de execucao PowerShell (se nao foi limpo)
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/ScriptBlock" |
  Where-Object { $_.Message -match "rundll32|pushd|WebDAV|@ssl" } |
  Select-Object TimeCreated, Message -First 10

# 4. Verificar conexoes WebDAV activas
netstat -an | findstr ":443"
# Procurar ligacoes a hosts com @SSL (WebDAV over HTTPS)

# 5. Verificar processos pythonw suspeitos
Get-Process pythonw -ErrorAction SilentlyContinue |
  Select-Object Id, Path, StartTime

# 6. Remover scheduled task maliciosa
Unregister-ScheduledTask -TaskName "NomeDaTaskSuspeita" -Confirm:$false

Passo 4: Análise de Impacto e Notificação

7. Prevenção: Defender SmartScreen, AppLocker/WDAC, MFA, Password Managers

A prevenção é sempre mais barata que a resposta a incidente. Para PMEs, uma estratégia de defesa em profundidade contra infostealers combina controlo de aplicações, filtering web, autenticação forte e gestão de credenciais.

Defender SmartScreen e Web Content Filtering

O Defender SmartScreen é a primeira linha de defesa contra malvertising e SEO poisoning — os vectors iniciais do ClickFix. SmartScreen avalia URLs e downloads contra listas de reputação da Microsoft, bloqueando sites maliciosos conhecidos antes que o utilizador os abra.

Para PME com Defender for Endpoint Plan 1 ou 2, activar também Web Content Filtering para bloquear categorias de sites não-essenciais para o negócio (jogos, ficheiros partilhados, sites recém-registados). Isto reduz drasticamente a superfície de campanhas onde o ClickFix podem aparecer.

AppLocker e Windows Defender Application Control (WDAC)

O AppLocker e WDAC são as ferramentas nativas de application control em Windows. ACR Stealer depende de executar rundll32.exe, mshta.exe, pythonw.exe e PowerShell de directórios user-writable. Application control pode bloquear estas execuções:

# AppLocker via GPO ou Intune - regras recomendadas para infostealer:

# 1. Bloquear execucao de .exe em %LocalAppData%\Temp
New-AppLockerPolicy -RuleType Path -Path "%LOCALAPPDATA%\Temp\*" `
    -Action Deny -User "Everyone" -Description "Block Temp exec"

# 2. Bloquear execucao de .py e pythonw.exe fora de paths aprovados
New-AppLockerPolicy -RuleType Path -Path "*\pythonw.exe" `
    -Action Deny -User "Everyone" -Description "Block pythonw"
# (Permitir apenas em C:\Python*\ ou C:\Program Files\Python*\)

# 3. Bloquear mshta.exe de URLs/remoto
New-AppLockerPolicy -RuleType Path -Path "*\mshta.exe" `
    -Action Deny -User "Everyone" -Description "Block mshta"
# (Se a organizacao nao precisa de HTA, bloquear completamente)

# 4. Bloquear rundll32 de carregar DLLs de paths remotos/WebDAV
# WDAC e mais adequado para este caso - ver deployment guide:
# https://learn.microsoft.com/en-us/windows/security/threat-protection/
#   windows-defender-application-control/windows-defender-application-control-deployment-guide

WDAC é mais robusto que AppLocker (funciona em kernel mode, é mais difícil de contornar), mas requer mais planeamento. Para PME sem equipa de segurança dedicada, começar com AppLocker em modo Audit durante 2-4 semanas para perceber o que seria bloqueado, depois migrar para Enforce.

MFA e Conditional Access

O Conditional Access do Entra ID é essencial para mitigar o impacto de credenciais roubadas. Mesmo que o infostealer roube a password, MFA bem configurado impede o uso directo. No entanto, como vimos, cookies de sessão podem bypassar MFA — por isso o Conditional Access deve incluir:

• Session controls: limitar duração de sessões web, forçar re-autenticação periódica
• Sign-in frequency: configurar para 1-4 horas (não 24h) para serviços sensíveis
• Persistent browser session: desactivar — sessions não persistem após fechar browser
• Conditional Access com compliance: exigir dispositivo compliant (Intune) para acesso a M365
• Block legacy authentication: protocolos POP3/IMAP/SMTP básico não suportam MFA

Password Managers em vez de Browser Storage

A maior parte do roubo de credenciais pelos infostealers targeting browsers depende de as passwords estarem guardadas no browser (Chrome, Edge) e acessíveis via DPAPI. Um password manager dedicado (Bitwarden, 1Password, Keeper) reduz esta superfície porque:

• As credenciais não estão na SQLite DB do browser — o infostealer não as encontra nos sítios habituais
• O cofre do password manager tem encriptação própria independente da DPAPI do Windows
• O preenchimento automático requer interacção do utilizador (master password ou biometria)
• Os password managers enterprise têm auditoria de acessos e relatórios de credenciais fracas

Tamper Protection e EDR em Block Mode

Duas configurações críticas que devem estar sempre activas: Tamper Protection impede administradores locais de desactivar o Defender; EDR em Block Mode permite que detecções comportamentais bloqueiem e remediem ameaças mesmo se o Defender Antivirus estiver em modo passivo (ex: com outro AV).

# Verificar Tamper Protection
Get-MpComputerStatus | Select-Object IsTamperProtected

# Verificar EDR em Block Mode (requer Defender for Endpoint Plan 2)
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusEnabled

# Activar cloud-delivered protection (essencial para deteccao comportamental)
Set-MpPreference -MAPSReporting Advanced
Set-MpPreference -SubmitSamplesConsent SendSafeSamples
Set-MpPreference -CloudBlockLevel High
Set-MpPreference -CloudExtendedTimeout 50

8. Ferramentas de Análise: Threat Hunting com KQL Queries

O Advanced Hunting do Defender XDR permite procurar proativamente indicadores de ACR Stealer (e outros infostealers) em toda a rede usando KQL (Kusto Query Language). As queries abaixo são adaptadas das publicadas pela Microsoft no relatório de Julho 2026.

Query 1: Detectar Comandos ClickFix (RunMRU)

Esta query procura comandos executados via ClickFix que ficam registados na chave RunMRU do registry. Detecta as variantes rundll32 com WebDAV e conhost --headless:

// ACR Stealer - ClickFix via RunMRU
// Procurar comandos rundll32 com WebDAV @SSL ou conhost --headless
DeviceRegistryEvents
| where RegistryKey has "RunMRU"
| where (RegistryValueData has_all ("rundll32", "@ssl", " /c ", " start ")
    and (RegistryValueData matches regex @"\\[^\\]+@ssl\\[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\\\w+\.\w+,#1"
     or RegistryValueData matches regex @"(?i)pushd \\[^\\]+@ssl\\[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12} "))
  or (RegistryValueData has_all ("@ssl", " /c ", "conhost --headless ")
      and RegistryValueData contains "rundll32")
| project Timestamp, DeviceName, RegistryValueData, InitiatingProcessAccountName

Query 2: Scheduled Task de Persistência

Detecta a scheduled task criada pelo PowerShell loader, mascarada de auto-update com padrão de data no nome:

// ACR Stealer - Scheduled Task persistence (Campanha 1)
// PowerShell cria task com nome "Autoupdate" + padrao de 8 digitos
DeviceProcessEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| where InitiatingProcessCommandLine has_all ("-Command", "powershell")
| where ProcessCommandLine has_all ("schtasks", " /run /tn ", " Autoupdate ")
    and ProcessCommandLine matches regex "[0-9]{8}"
| project Timestamp, DeviceName, InitiatingProcessCommandLine,
    ProcessCommandLine, AccountName

Query 3: MSHTA via PowerShell (Campanha 2)

// ACR Stealer - MSHTA launch via PowerShell (Campanha 2)
// MSHTA a carregar HTA remoto via URL com padrao de 7 digitos
DeviceProcessEvents
| where InitiatingProcessParentFileName has "explorer.exe"
| where InitiatingProcessFileName =~ "powershell.exe"
    and InitiatingProcessCommandLine in~ ('"PowerShell.exe" ', '"PowerShell.exe"')
| where ProcessCommandLine has_all ('"mshta.exe" https://')
    and ProcessCommandLine matches regex "/[0-9]{7}"
| project Timestamp, DeviceName, InitiatingProcessCommandLine,
    ProcessCommandLine, AccountName

Query 4: Acesso a Browser Credential Stores (DPAPI)

Esta query genérica detecta processos não-browser a aceder às bases de dados de credenciais do Chrome/Edge — um indicador forte de infostealer:

// Infostealer - Acesso a browser credential stores por processos nao-browser
DeviceFileEvents
| where FileName in~ ("Login Data", "Login Data-journal", "Cookies",
                       "Cookies-journal", "Web Data", "Web Data-journal")
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe",
    "brave.exe", "firefox.exe", "opera.exe")
| where InitiatingProcessFileName !in~ ("SearchIndexer.exe", "MsMpEng.exe")
| project Timestamp, DeviceName, FileName, FolderPath,
    InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
| top 100 by Timestamp

Query 5: Comunicação com IOCs conhecidos do ACR Stealer

// ACR Stealer - Comunicacao com C2 domains conhecidos
let acrC2Domains = dynamic([
    "looksta.icu", "contrite.quirksturdy.icu", "ux.strainedeasily.icu",
    "cpppemwjewjoiwejow.sale", "breaksd.wifihot.icu",
    "walter.filloco.icu", "fast.raidher.icu", "apigrokcloud.icu",
    "enhanceblabber.cc", "deep-harborio.com", "auramatrixa.com",
    "zealpraxis.com", "prism-vertex.com", "prism-matrixs.com",
    "proton-network.com", "creativecommunityinfo.art"
]);
DeviceNetworkEvents
| where RemoteUrl has_any (acrC2Domains) or RemoteDnsDomain has_any (acrC2Domains)
| project Timestamp, DeviceName, RemoteUrl, RemoteDnsDomain,
    RemoteIP, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

9. Erros Comuns na Gestão de Infostealers em PME

10. Checklist Rápido de Verificação