Cyble Vision, CloudSEK XVigil

Nota da subpasta 01 - Threat Intelligence Platforms (TIPs), no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata das plataformas de exposição digital e dark web Cyble Vision e CloudSEK XVigil, com foco em credenciais vazadas, abuso de marca e risco de cadeia de suprimentos.
Dialoga com a nota de Recorded Future, Anomali e ThreatConnect da mesma pasta, com a nota de dark web do Capítulo 02 e com o controle INT.3 de integração EASM com CTI do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

As TIPs clássicas da nota 01 desta pasta se concentram em indicadores e em contexto de ameaça para detecção. Existe, porém, uma segunda família de plataformas comerciais cuja unidade de análise não é o IOC do adversário, e sim a superfície exposta da própria organização: credenciais corporativas circulando em dumps, domínios registrados para se passar pela marca, buckets abertos, aplicações móveis mal construídas e vazamentos que mencionam fornecedores. O Capítulo 06 da biblioteca tratou do dark web como fonte de coleta e o controle INT.3 do Capítulo 15 descreveu a integração entre EASM e CTI; esta nota apresenta as ferramentas que industrializam essa operação.

Duas plataformas guiam o estudo: Cyble Vision, da Cyble, e CloudSEK XVigil, da CloudSEK. Ambas se encaixam na categoria de digital risk protection e external exposure monitoring, com combinações próprias de monitoramento de dark web, mídia social, marketplaces, pastes, infraestrutura externa e cadeia de suprimentos. A escolha entre elas, ou entre elas e o módulo de exposição de uma TIP maior, depende de quão central a vigilância da própria superfície é para o programa: quando o requisito de inteligência principal é saber o que o adversário já tem da organização, essa família de produto passa a ser candidata natural ao orçamento.

O corte entre as duas famílias é o objeto de trabalho: a TIP de catálogo responde o que o adversário usa, e a plataforma de exposição responde o que o adversário já sabe da organização. As notas de EASM do Capítulo 04 e de dark web do Capítulo 02 cobrem os fundamentos conceituais; aqui o foco é o produto que executa essa vigilância com cobertura, evidência e fluxo de resposta. Os critérios da comparação entre Cyble e CloudSEK transbordam para qualquer avaliação da categoria, o que faz desta nota também um gabarito de seleção.

2. O Problema que Essa Família Resolve

A pergunta operacional que essas plataformas respondem é desconfortável e contínua: o que já está vazando sobre a organização hoje, fora do perímetro, em lugares que a equipe de segurança não controla? A resposta exige presença automatizada em ambientes que nenhum time consegue cobrir manualmente com credibilidade, incluindo fóruns e marketplaces da dark web, canais de Telegram e Discord, pastes e repositórios de código, infraestrutura de e-mail e DNS, lojas de aplicativos e redes sociais. A nota de dark web do Capítulo 02 explica por que a coleta manual nesse ecossistema é lenta e perigosa; as plataformas resolvem com coleção em escala, indexação e alertas.

A cobertura desejada combina cinco famílias de fonte: fóruns e marketplaces da dark web, canais fechados de mensageria, pastes e repositórios de código, infraestrutura de e-mail e DNS usada em abuso, e mídia social e lojas de aplicativos. Nenhuma equipe cobre esse leque com busca manual com credibilidade estatística, porque o volume de novos posts e canais diários supera qualquer capacidade humana. A proposta de valor das plataformas é exatamente transformar esse leque em indexação consultável, com alertas por escopo definido e evidência anexada.

O segundo problema é a latência entre o vazamento e a ação. Uma credencial de VPN aparece num dump hoje e é usada em ataque de acesso inicial na mesma semana, padrão recorrente em casos públicos de grupos como Scattered Spider e de afiliados de ransomware como LockBit e ALPHV. O valor da plataforma é reduzir esse intervalo a horas, com alerta acionável que dispara redefinição de senha, revisão de MFA e verificação de sessões ativas, em vez de descobrir o vazamento meses depois durante um incidente. O terceiro problema é o abuso de marca, com domínios typosquatting e páginas de phishing que precisam ser derrubadas, processo que as plataformas também aceleram com takedowns.

Os vazamentos que mais acionam o programa seguem padrão conhecido: dumps de stealer com credenciais de navegador corporativo, listas de acesso revendidas em fóruns, bases de clientes expostas por erro de terceiros e repositórios com segredos versionados por engano. Cada tipo tem rota de resposta diferente, e a plataforma ganha valor quando classifica o tipo na fonte, porque credencial de stealer pede resposta imediata de acesso, enquanto base de clientes pede fluxo de LGPD e comunicação com o jurídico. A separação correta dessas rotas é o que evita a resposta genérica que trata todo vazamento como incidente de credencial.

3. Cyble Vision: Capacidades e Diferenciais

O Cyble Vision organiza o trabalho em módulos de monitoramento que cobrem dark web, deep web, mídia social, pastes, fóruns de ransomware e vazamentos de código, combinados com um módulo de superfície de ataque externa que inventaria ativos expostos e vulnerabilidades associadas. O diferencial percebido em operação é a profundidade da coleta em ambientes de língua russa e asiática, com cobertura de marketplaces e canais fechados, e a entrega de inteligência de ameaça com perfis de grupos de ransomware e seus sites de vazamento, úteis tanto para monitorar menções à organização quanto para acompanhar vítimas do setor.

A partir dos alertas, o produto segue o fluxo clássico de digital risk protection: detecção, enriquecimento, triagem com contexto, notificação e suporte a takedown. A configuração típica de um ativo monitorado ilustra o modelo de escopo por palavras-chave e domínios.

# Exemplo de escopo de monitoramento no fluxo de configuração do produto
organizacao:
  dominios: [empresa.com.br, empresa-cdn.com]
  marcas: [EmpresaX, XPay]
  palavras_chave_executivos: [ceo-empresa.com.br, "diretoria financeira"]
  termo_cnpj: "12.345.678/0001-90"
fontes_monitoradas: [darkweb, telegram, pastes, github, ransomware-blogs]
alertas_para: [cti-quadro, soc-pagerduty]
prioridade_automatica: credenciais, executivos, malware-stager

O fluxo de takedown é o acompanhamento natural do monitoramento de marca, e a maturidade dele se mede em horas, não em semanas. A tabela descreve as etapas e os prazos de referência para um domínio de phishing confirmado.

O alerta de credencial é o caso de uso com maior retorno imediato, e o produto entrega a evidência com screenshot e trecho do dump, classificação de confiança e recomendação de ação. Para o time de CTI, a agregação de menções por grupo criminoso alimenta a análise de campanhas do Capítulo 05, porque a plataforma registra quando e onde a organização apareceu no ecossistema criminoso.

A qualidade da evidência é o critério de avaliação número um dessa categoria de produto. Captura do dump, trecho visível, data de coleta e canal de origem são o mínimo para que a triagem avance sem reabrir investigação manual, e alertas que citam fontes sem evidência devem ser contados e cobrados do fornecedor. Em prova de conceito, a proporção de alertas com evidência utilizável é o número que decide o contrato.

4. CloudSEK XVigil: Capacidades e Diferenciais

O CloudSEK XVigil posiciona-se como plataforma de digital risk protection com três frentes explícitas: monitoramento da superfície e da dark web por ameaças à marca e a dados, monitoramento de infraestrutura exposta e proteção de marca com takedown. A suíte da CloudSEK completa-se com produtos complementares que frequentemente aparecem na avaliação: o BeVigil, voltado à segurança de aplicações móveis da própria organização, e o SVigil, voltado ao risco de cadeia de suprimentos e terceiros. Em comparação com o Cyble, o diferencial percebido é a força em triagem de abuso de marca e em correlação entre exposição externa e risco concreto, apoiada na classificação de severidade dos achados.

O fluxo operacional típico começa no inventário da pegada digital da organização, segue com o monitoramento contínuo por menções e mudanças, e termina em alertas classificados por severidade com evidência. A tabela resume as capacidades transversais das duas plataformas e como elas se traduzem em casos de uso do programa de CTI-TH.

Na prática, o XVigil encaixa bem em operações com forte presença digital ao consumidor, em que a cadência de phishing contra clientes é alta e o takedown é processo frequente. A classificação de severidade embutida nos achados, combinada com evidência visual, reduz a triagem do analista ao essencial, e a integração por API leva o alerta de marca ao mesmo case management da nota 01 desta pasta. Para o hunter, os achados de infraestrutura exposta funcionam como agenda de correção externa, priorizada pelo mesmo critério dos achados internos.

5. Comparação e Critérios de Escolha

A comparação honesta entre as duas plataformas começa pelo desenho da organização. Organizações com grande pegada de marca ao consumidor, muitas aplicações móveis e histórico de phishing sofisticado tendem a extrair mais valor do conjunto CloudSEK, com XVigil na frente e BeVigil e SVigil cobrindo apps e terceiros. Organizações cuja dor prioritária é visibilidade ampla em ecossistemas criminosos, incluindo acompanhamento de grupos de ransomware e de canais em múltiplos idiomas, tendem a valorizar a coleta do Cyble. Em ambas, o custo real está na triagem dos alertas, e não na licença, e o fator decisivo costuma ser a qualidade do contexto que acompanha cada alerta, porque um dump sem evidência e sem classificação gera trabalho extra em vez de economizá-lo.

Três critérios verificáveis ajudam a decidir. Primeiro, pedir uma prova de conceito com o domínio real da organização e medir quantos alertas de credencial vêm com evidência utilizável versus quantos exigem investigação manual. Segundo, testar o fluxo de takedown de um domínio typosquatting real e medir o tempo médio de resolução. Terceiro, avaliar as integrações com TIP, SIEM e SOAR do parque, porque o valor dessas plataformas se multiplica quando o alerta de credencial entra no playbook do Capítulo 11 e no case management descrito na nota 01 desta pasta. Os controles INT.3 e INT.4 do Capítulo 15 definem como os achados de exposição se conectam com a caça, por exemplo consultando autenticações da conta vazada na janela anterior ao alerta.

A tabela de cenários resume a inclinação recomendada por perfil de organização, e serve de abertura para a prova de conceito.

6. Fluxo Operacional de Credencial Vazada

O caso de credencial vazada concentra a maior parte dos alertas e justifica uma rota operacional fixa, testada e medida. O fluxo a seguir assume integração com o SOAR do Capítulo 11 e telemetria de identidade do Capítulo 08, e cada etapa tem dono e prazo definidos no runbook do programa.

A caça retroativa da etapa 3 é o elo com o hunting e merece consulta pronta. O padrão a seguir recupera autenticações do usuário afetado entre o primeiro aparecimento do dump e o momento do alerta, e se replica para VPN, e-mail e SSO conforme os logs disponíveis.

SigninLogs
| where UserPrincipalName == "usuario@empresa.com.br"
  and TimeGenerated between (datetime(2025-11-08) .. datetime(2025-11-18))
| project TimeGenerated, AppDisplayName, IPAddress, LocationDetails,
          ResultDescription, ConditionalAccessStatus
| order by TimeGenerated asc

O gatilho da rota no SOAR segue o desenho abaixo, com campos exigidos na entrada e rotas distintas por criticidade da conta.

gatilho: alerta_exposicao_credencial
origem: plataforma_de_exposicao
campos_exigidos: [email, fonte, data_dump, evidencia_url]
rota:
  executivo: pager_executivo, contencao_1h
  padrao: fila_cti, contencao_4h
  evidencia_ausente: devolver_ao_fornecedor
metricas: tempo_triagem, tempo_contencao, taxa_confirmacao

O resultado da caça decide a gravidade do caso: nenhuma autenticação de origem desconhecida reclassifica o alerta como exposição administrada, com monitoramento continuado, enquanto qualquer login suspeito no intervalo promove o caso a resposta a incidente pela esteira do Capítulo 13. As métricas da rota ficam públicas no dashboard do programa: tempo de triagem, tempo até contenção, proporção de alertas confirmados e recidiva por conta. Sem essas medidas, a rota degrada para fila de e-mails, e o orçamento da plataforma fica indefensável na próxima renovação.

7. Erros Comuns e Pontos de Atenção

• Tratar todo alerta de credencial como verdadeiro: dumps de terceiros e listas reutilizadas geram falsos positivos em volume, e a nota de avaliação de credibilidade de fontes do Capítulo 05 deve guiar a triagem antes de qualquer reset em massa.
• Monitorar sem escopo definido, com centenas de palavras-chave genéricas que geram ruído; o escopo deve cobrir domínios, marcas, executivos e CNPJ, revisado a cada trimestre.
• Deixar o takedown como processo informal, sem responsável e sem medidor de tempo, quando é justamente o fluxo que protege clientes de phishing ativo.
• Ignorar os achados de terceiros e de supply chain por falta de alçada, quando o correto é ter rota formal para o programa de gestão de riscos de terceiros com prazo de resposta.
• Não integrar os alertas ao SOC e ao SIEM, deixando a plataforma como portal isolado consultado semanalmente; a credencial vazada perde valor a cada hora sem ação.
• Confinar o uso à resposta reativa, desperdiçando o acervo de menções por grupo criminoso, que alimenta hipóteses de caça e análise de campanhas do Capítulo 05.
• Promover executivos à lista de monitoramento sem alinhamento com RH e jurídico, criando atrito de privacidade que paralisa a resposta; o escopo de monitoramento de pessoas precisa de patrocínio formal.
• Medir a plataforma por número de alertas gerados, quando a métrica que importa é tempo até contenção por alerta confirmado, na régua dos KPIs do Capítulo 16.
• Deixar de atualizar o escopo quando a organização muda de marca, domínio ou estrutura, monitorando o passado e perdendo o presente.

8. Integração com o Restante da Biblioteca

Os alertas dessas plataformas são entradas do ciclo de inteligência do Capítulo 01, com coleta externa, processamento e disseminação para públicos distintos, e os indicadores que delas saem podem ser registrados no OpenCTI ou no MISP da nota 03 desta pasta, mantendo o controle PLT do Capítulo 15 coeso. A conexão com o hunting é direta pelo controle INT.4, que transforma cada alerta de exposição em caça retroativa na telemetria de identidade, VPN e e-mail do Capítulo 08. A nota de dark web do Capítulo 02 fornece o contexto de coleta, e a nota de EASM do Capítulo 04 explica a taxonomia da superfície externa que os módulos de infraestrutura dessas plataformas inventariam.

Para programas em construção, a recomendação de sequência é prática: primeiro inventariar a pegada digital e fechar o básico de exposição, depois ativar o monitoramento de credenciais com rota de resposta testada, em seguida os demais módulos. O papel de fechamento desta nota é situar a família de produto no orçamento do capítulo: quando a pergunta central do programa é o que o adversário já tem da organização, Cyble Vision e CloudSEK XVigil são respostas comerciais maduras, e a decisão entre elas deve ser guiada por prova de conceito com dados reais, e nunca por tabela de funcionalidades.

A ordem de compra entre a família de exposição e a TIP de catálogo deve refletir os PIRs do Capítulo 01: para a maioria das operações com phishing local ativo, o monitoramento de credenciais e de marca tem prioridade prática sobre mais um catálogo de IOC. Quando os dois existem, o contrato de dados é simples, com alertas de exposição virando indicadores e casos na TIP, e o grafo guardando o histórico de abuso por campanha. Com isso, a análise de phishing do Capítulo 08 passa a trabalhar com série temporal de infraestrutura adversária, e o orçamento do capítulo fecha com as duas famílias cobrindo os dois lados da pergunta central.