Infraestrutura do First VPN Service foi associada a reconhecimento de redes, intrusões, furto de dados, varreduras e ataques de negação de serviço por clientes criminosos.
| Componente | First VPN Service, rede privada virtual criminosa com nós de saída distribuídos em 27 países e protocolos como OpenConnect, WireGuard, Outline, VLess TCP Reality, OpenVPN ECC, L2TP/IPSec e PPtP. |
| Vetor | Uso pago da infraestrutura para mascarar a origem de tráfego associado a ransomware, reconhecimento de rede, intrusões, fraude em larga escala, furto de dados, varreduras e negação de serviço. |
| Impacto | A infraestrutura foi usada por ao menos 25 grupos de ransomware, incluindo Avaddon Ransomware, para ocultar identidade e origem de conexões durante atividades criminosas. |
| Prioridade | Revisar telemetria de rede, autenticação, proxy, VPN, EDR e perímetro para conexões compatíveis com nós de saída, protocolos e padrões de tráfego atribuídos ao serviço. |
| Infraestrutura | A operação internacional ocorreu entre 19 e 20 de maio e incluiu derrubada de 33 servidores, apreensão de infraestrutura, entrevista do administrador e busca residencial na Ucrânia. |
| Operação | A ação foi liderada por França e Países Baixos, com apoio de Luxemburgo, Romênia, Suíça, Ucrânia, Reino Unido, Canadá, Alemanha, Estados Unidos, Espanha, Suécia, Dinamarca, Estônia, Letônia, Lituânia, Polônia e Portugal. |
| Pagamentos | As assinaturas variavam de um dia a um ano, com preços entre US$ 2 e US$ 483, aceitando Bitcoin, Perfect Money, Webmoney, EgoPay e InterKass. |
Autoridades da Europa e da América do Norte desarticularam o First VPN Service, uma infraestrutura de VPN apresentada ao mercado criminoso como serviço de anonimização para operações que exigiam ocultação de origem. O serviço foi usado para mascarar conexões associadas a ransomware, furto de dados, reconhecimento de redes, varreduras, fraudes em larga escala e ataques de negação de serviço. A relevância técnica do caso está no papel operacional da VPN: ela não aparece como malware nem como exploração de uma falha específica, mas como camada de infraestrutura usada por operadores para reduzir atribuição, dificultar bloqueios por origem e embaralhar a análise de tráfego durante fases iniciais e intermediárias de ataques.
A ação internacional ocorreu entre 19 e 20 de maio e teve como resultado a derrubada de 33 servidores, a apreensão de infraestrutura usada para dar suporte a atividade cibercriminosa global, a entrevista do administrador do serviço e uma busca residencial na Ucrânia. A investigação era apoiada desde dezembro de 2021 por vários países, com liderança de França e Países Baixos. O First VPN Service estava ativo desde aproximadamente 2014 e mantinha 32 nós de saída em 27 países, incluindo três nos Estados Unidos. Essa dispersão geográfica permitia que clientes criminosos escolhessem rotas de saída compatíveis com suas necessidades operacionais, reduzindo a utilidade de bloqueios baseados apenas em país ou reputação genérica de provedor.
O serviço era anunciado em fóruns russófonos de cibercrime, incluindo Exploit[.]in e XSS[.]is, com mensagens centradas em anonimato, estabilidade e ausência de cooperação com autoridades judiciais. A infraestrutura aceitava pagamentos por Bitcoin, Perfect Money, Webmoney, EgoPay e InterKass, com assinaturas de um dia a um ano e valores entre US$ 2 e US$ 483. Essa elasticidade de preço e duração favorecia tanto uso episódico, como uma varredura ou uma tentativa de intrusão, quanto uso prolongado em campanhas com várias etapas. Ao menos 25 grupos de ransomware, incluindo Avaddon Ransomware, teriam usado a infraestrutura para reconhecimento de rede e intrusões.
O fluxo operacional do First VPN Service combinava acesso por assinatura, nós de saída em múltiplas jurisdições, suporte técnico direto e protocolos variados para encapsular ou disfarçar conexões. O serviço oferecia OpenConnect, WireGuard, Outline e VLess TCP Reality, além de opções de criptografia ou tunelamento como OpenVPN ECC, L2TP/IPSec e PPtP. Essa variedade permitia que usuários escolhessem perfis diferentes de tráfego conforme o alvo, o ambiente de rede e o grau de inspeção esperado. Em ambientes com filtragem simples, um túnel VPN convencional poderia ser suficiente; em redes com inspeção mais rígida, opções voltadas a camuflar tráfego como HTTPS aumentavam a chance de atravessar controles sem chamar atenção imediata.
Entre as opções descritas, VLESS e Reality tinham valor operacional específico porque permitiam disfarçar tráfego de VPN como tráfego HTTPS em portas normalmente usadas para conexão a sites. Para defensores, esse detalhe é importante porque o tráfego pode se misturar ao volume normal de navegação criptografada, especialmente quando a análise se limita a porta, protocolo aparente ou destino geográfico. A detecção, nesse cenário, depende de correlação com comportamento: sequência de conexões, horários incomuns, volume, destinos raros para a organização, origem do processo no endpoint, falhas de autenticação próximas no tempo e ações subsequentes em serviços internos.
A cadeia de uso por grupos de ransomware descrita no material se concentra em reconhecimento e intrusão. Isso indica emprego como infraestrutura de apoio para acessar alvos, enumerar superfícies, ocultar scanners e reduzir a exposição de endereços originais dos operadores. O serviço também foi associado a furto de dados, fraude em larga escala e ataques de negação de serviço, mas o impacto deve ser tratado conforme a telemetria de cada ambiente. A presença de tráfego compatível com essa infraestrutura não confirma, isoladamente, criptografia de arquivos, comprometimento de domínio, exfiltração bem-sucedida ou movimentação lateral; ela indica necessidade de investigação sobre a sessão, a conta, o ativo de origem e as ações realizadas após a conexão.
O suporte por servidor Jabber próprio e Telegram reforçava a maturidade operacional do serviço. Suporte técnico desse tipo reduz barreiras para operadores menos sofisticados, padroniza o uso da infraestrutura e acelera a resolução de bloqueios, falhas de configuração ou necessidade de troca de protocolo. Do ponto de vista defensivo, isso significa que a VPN funcionava como serviço criminoso gerenciado, não como coleção improvisada de proxies descartáveis. A combinação de assinatura curta, múltiplos meios de pagamento e promessa de ausência de logs criava uma camada de anonimização comercializada para clientes que precisavam executar ações ofensivas sem manter sua própria rede de saída.
A superfície exposta inclui qualquer ambiente que tenha recebido conexões de nós de saída do First VPN Service ou observado tráfego compatível com os protocolos oferecidos pelo serviço em janelas associadas a reconhecimento, autenticação suspeita, varredura, exploração ou transferência de dados. O material descreve nós de saída em Austrália, Áustria, Bélgica, Canadá, Chipre, Finlândia, França, Alemanha, Hong Kong, Itália, Letônia, Luxemburgo, Moldávia, Países Baixos, Panamá, Polônia, Romênia, Rússia, Sérvia, Singapura, Espanha, Suécia, Suíça, Turquia, Ucrânia, Reino Unido e Estados Unidos. Três nós de saída estavam nos Estados Unidos. A lista amplia o escopo de análise porque destinos ou origens em países considerados comuns para negócios legítimos não devem ser descartados automaticamente.
Organizações que operam serviços expostos à internet, portais de autenticação, VPN corporativa, painéis administrativos, aplicações web, gateways de e-mail, serviços de transferência de arquivos, RDP protegido por camada externa, SSH, APIs e interfaces de nuvem devem tratar a atividade como um problema de identidade e perímetro. Uma conexão originada de VPN criminosa pode aparecer antes de senha válida, tentativa de força bruta, enumeração de usuário, exploração de aplicação, varredura de portas ou teste de credenciais reutilizadas. A ação defensiva mais eficiente é reconstruir a linha do tempo por ativo e identidade, em vez de procurar apenas um indicador de rede isolado.
A promessa pública de não armazenar registros e de não cooperar com autoridade judicial era parte do posicionamento do serviço, mas defensores não devem depender dessa declaração para estimar risco. Mesmo que o provedor afirmasse armazenar apenas e-mail e nome de usuário, a organização vítima normalmente precisa trabalhar com seus próprios registros: autenticação, endpoint, proxy, firewall, DNS, EDR, WAF, gateway de VPN e eventos de aplicação. A investigação deve determinar se houve apenas contato externo bloqueado, sessão autenticada, execução de comando, upload, consulta a dados sensíveis, alteração de permissão ou preparação para extorsão.
- Serviços expostos à internet que receberam conexões de países onde havia nós de saída do First VPN Service.
- Portais de autenticação com falhas, sucesso incomum ou sequência de tentativas vindas de infraestrutura VPN.
- Aplicações e APIs com varredura, enumeração de rotas, erros 401, 403, 404 ou 500 concentrados em curtas janelas.
- Gateways de rede que registraram
OpenConnect,WireGuard,Outline,VLess TCP Reality,OpenVPN ECC,L2TP/IPSecouPPtPem contexto incompatível com uso corporativo autorizado.
A caça deve começar por uma linha do tempo centrada em conexões externas e autenticação. Como o serviço era usado para ocultar origem, a análise precisa unir eventos de rede com identidade e endpoint. Um endereço de saída de VPN pode aparecer em logs de WAF, firewall, proxy reverso, IdP, VPN corporativa, EDR ou aplicação. O sinal ganha peso quando a conexão é seguida por enumeração de usuários, múltiplas tentativas de senha, mudanças de localização impossíveis, criação de sessão em horário incomum, alteração de fator de autenticação, consulta massiva a diretórios, acesso a compartilhamentos ou tráfego de saída acima do perfil normal do ativo.
Em rede, o foco deve estar em padrões de encapsulamento e camuflagem. VLESS com Reality pode se apresentar como HTTPS em portas comuns de navegação, o que exige inspeção comportamental e não apenas assinatura simples. Conexões longas, destinos raros, volumes assimétricos, repetição de handshakes, uso de clientes não aprovados e sessões iniciadas por processos fora do padrão do usuário são sinais úteis. Para WireGuard, OpenConnect, Outline, OpenVPN ECC, L2TP/IPSec e PPtP, a organização deve distinguir uso corporativo autorizado de clientes instalados sem justificativa, serviços iniciados manualmente e conexões em hosts que não fazem parte do parque de VPN aprovado.
Em identidade, a telemetria deve cobrir sucesso após falhas, alterações de localização, login por ASN ou país incomum, criação de tokens, novas chaves, consentimentos de aplicação, troca de senha e registro de novos dispositivos. Em endpoint, procure instalação ou execução de clientes VPN não aprovados, arquivos de configuração, serviços persistentes, processos de tunelamento e conexões iniciadas pouco antes de atividade administrativa. Em aplicações, investigue picos de erros, enumeração de endpoints, uso anormal de métodos HTTP, alteração de permissões e exportações de dados. A correlação temporal é decisiva: a VPN é a camada de transporte; o dano real depende das ações que vieram depois.
- Sessões autenticadas originadas de países ou provedores que não fazem parte do padrão normal do usuário ou da aplicação.
- Conexões HTTPS longas ou repetidas para destinos raros, especialmente quando associadas a processos de VPN ou tunelamento.
- Tentativas de reconhecimento de portas, rotas web, usuários, compartilhamentos ou APIs antes de uma autenticação bem-sucedida.
- Uso de
OpenConnect,WireGuard,Outline,VLess TCP Reality,OpenVPN ECC,L2TP/IPSecouPPtPfora de políticas aprovadas. - Eventos de endpoint indicando instalação, execução ou configuração de cliente VPN sem mudança autorizada.
A resposta deve priorizar contenção baseada em identidade, perímetro e validação de atividade pós-conexão. Bloquear apenas países ou portas é insuficiente porque o serviço possuía nós de saída em 27 países e podia disfarçar tráfego como HTTPS. O primeiro passo é identificar ativos e contas que receberam conexões suspeitas no período investigado, correlacionar com autenticação e determinar se houve sessão válida. Contas com sucesso de login anômalo devem passar por rotação de senha, revogação de sessões, revisão de fatores de autenticação, análise de tokens e verificação de alterações recentes. Ativos acessados devem ser avaliados por EDR, logs locais, integridade de serviços e sinais de execução remota.
No perímetro, revise regras de allowlist, exceções por geolocalização, exposição de painéis administrativos e controles de taxa. Serviços administrativos não devem depender apenas de segredo de URL, senha ou filtragem ampla por país. Para aplicações web e APIs, reforce autenticação multifator, limite de tentativas, proteção contra enumeração, alertas para erros anormais e registro detalhado de ações sensíveis. Em ambientes de nuvem, valide logs de controle, criação de chaves, alteração de políticas, consentimento de aplicações, movimentação de dados e acessos de contas privilegiadas em horários e origens incomuns.
A mitigação também exige governança sobre clientes VPN e protocolos dentro da rede corporativa. Defina quais ferramentas são autorizadas, monitore instalação de clientes não aprovados e bloqueie protocolos legados ou desnecessários quando não houver justificativa operacional. Onde PPtP ou L2TP/IPSec não forem necessários, a presença desses protocolos deve gerar investigação. Para tráfego que se apresenta como HTTPS, use análise de comportamento, inventário de destinos esperados e correlação com processo de origem. A validação final deve confirmar que não houve persistência, credenciais expostas, tarefas agendadas, chaves adicionadas, contas criadas, regras de firewall alteradas ou dados transferidos fora do padrão.
Como a operação derrubou servidores e apreendeu infraestrutura, defensores também devem aproveitar a janela para revisar incidentes antigos relacionados a ransomware, varreduras e autenticações incomuns. O serviço estava ativo desde aproximadamente 2014, portanto a investigação não deve se limitar ao dia da derrubada se houver sinais históricos de intrusão ou extorsão. A prioridade prática é transformar a informação de infraestrutura em hipóteses verificáveis: quais serviços receberam tráfego compatível, quais contas tiveram sucesso, quais comandos ou ações ocorreram depois e quais controles falharam em bloquear ou alertar.
- Correlacionar conexões suspeitas com autenticação, atividade de aplicação, endpoint e logs de rede antes de concluir impacto.
- Revogar sessões e revisar credenciais de contas com login anômalo associado a infraestrutura VPN ou localização incompatível.
- Bloquear ou alertar para protocolos VPN não autorizados e clientes de tunelamento instalados fora do padrão corporativo.
- Revisar exposição de painéis administrativos, APIs, gateways de VPN, RDP, SSH e aplicações web acessíveis pela internet.
- Validar ausência de persistência, criação de contas, alteração de permissões, execução remota e transferência de dados fora do perfil esperado.
0 Comentários