Pesquisadores do Have I Been Squatted em conjunto com Ctrl-Alt-Intel em fevereiro de 2026 relataram a descoberta de uma operação de phishing direcionada contra empresas de frete e logística nos EUA e Europa, que eles denominaram Diesel Vortex. Segundo eles, a campanha foi focada no roubo de credenciais para sistemas do setor: bolsas de carga, portais de transportadoras e corretores, além de circuitos de pagamento e combustível, onde a comprometimento do login frequentemente significa acesso direto a dinheiro ou a possibilidade de redirecionamento de pagamentos.
A única fonte pública de detalhes permanece sendo a publicação dos pesquisadores, enquanto que na grande mídia especializada e de cibersegurança, até o final de fevereiro de 2026, não foram encontradas confirmações ou investigações paralelas. Isso não refuta os fatos apresentados, mas faz com que o mercado veja a história como uma "investigação privada recente" que ainda não passou pelos mecanismos habituais de verificação independente. Detalhes, números e mecânica, apresentados abaixo, são baseados no relatório do Have I Been Squatted e parceiros: descrição do Diesel Vortex e da infraestrutura de phishing restaurada.
De acordo com o relatório, o período de atividade confirmado da campanha foi de setembro de 2025 a fevereiro de 2026. Os pesquisadores relatam 3.474 pares de login/senha interceptados, dos quais 1.649 são credenciais únicas. A telemetria das visitas às páginas de phishing, segundo eles, inclui 9.016 endereços IP únicos de visitantes. A infraestrutura envolveu 52 domínios, e a lista de endereços de contato alvo totalizou 75.840 e-mails (57.092 únicos). Esses números são importantes não por si só, mas porque mostram que não se tratava de um ataque pontual a um grande jogador, mas de um "funil" industrial com ampla distribuição, filtragem e "pressão" ativa sobre aqueles que clicaram.
Como exemplos de plataformas e processos para os quais foram preparados modelos, o relatório menciona DAT e Truckstop (no texto aparece a formulação "DAT Truckstop"), Central Dispatch, TIMOCOM, Teleroute, Highway, além da imitação de portais de grandes operadores e divisões logísticas, incluindo Penske Logistics. Um bloco separado é dedicado aos esquemas em torno do EFS (Electronic Funds Source) — isso já não é apenas um risco de vazamento de dados, mas também um potencial terreno para fraude de cheques/combustível e substituição de dados de pagamento. O relatório menciona 35 tentativas relacionadas a cheques EFS como um indicador observado de monetização.
Para o setor, as consequências da comprometimento de tais contas geralmente se encaixam em alguns cenários bem conhecidos no mercado: interceptação ou substituição de carga/destino, acesso a detalhes de remessas e contatos, abusos nas comunicações "transportadora-corretor-remetente", corretagem dupla, redirecionamento de faturas e alteração de instruções de pagamento. Com acesso a sistemas de pagamento e combustível, os riscos se tornam mais diretos: desde emissões/reemissões não autorizadas até tentativas de "retirar" dinheiro por meio de confirmações falsas.
Mantenha-se Atualizado com Notícias da Indústria
Inscreva-se em nossa newsletter e receba as últimas notícias da indústria de caminhões, atualizações de regulamentos e dicas de carreira diretamente em sua caixa de entrada.
Respeitamos sua privacidade. Cancele a inscrição a qualquer momento.
A característica chave do Diesel Vortex, segundo os pesquisadores, não é apenas a coleta de logins e senhas, mas um "operador no circuito", que em tempo real guia a vítima pelos passos necessários e intercepta códigos de uso único. O relatório menciona sinais de phishing por voz (vishing) em mensagens e logs restaurados, mas o canal central de controle era o Telegram.
A mecânica funcionava assim: a vítima caía em uma página de phishing, inseria login/senha, após o que o operador recebia uma notificação no Telegram e podia iniciar solicitações adicionais à vítima — por exemplo, pedir o código 2FA, mudar o fluxo para "login via Google/Microsoft/Yahoo", ou ao contrário, bloquear a sessão se algo desse errado. Essa abordagem visa a realidade mais comum na logística: muitas contas são protegidas por SMS/TOTP, o que funciona contra ataques "scriptados" em massa, mas protege mal contra um ataque onde a pessoa "captura" o código no momento de sua ação.
Métricas internas do relatório indiretamente confirmam o trabalho manual dos operadores: por exemplo, o comando/status “Invalid” foi usado 1.559 vezes em um conjunto de 4.657 solicitações — ou seja, os operadores frequentemente verificavam novamente ou "capturavam" a senha/código correto em uma janela de tempo limitada.
O relatório descreve a arquitetura de "dois domínios", que foi projetada para contornar listas de bloqueio e mecanismos de segurança dos navegadores. No topo, o usuário via um domínio "decente" (frequentemente na zona .com) — um domínio "publicitário" condicional. Mas o próprio formulário de phishing era carregado dentro de um iframe em tela cheia de um segundo domínio — "sistêmico", frequentemente nas zonas .top ou .icu. Na lógica dos pesquisadores, isso aumentava a durabilidade do esquema: mesmo que o domínio "de conteúdo" fosse bloqueado, a "vitrine" poderia viver mais tempo, e a rotação de domínios se tornava mais barata e rápida.
Em seguida, entrava em ação um "funil" de múltiplos estágios para filtrar visitantes indesejados. São mencionados planejamento de inclusão de links, alternadores de atividade de modelos/domínios, filtragem IP/ISP/ASN com base no ipinfo.io, filtragem por user-agent (para bots e sandboxes), parâmetros e "portões" por URL, listas de bloqueio, bem como tokens para iframe. O relatório também fornece detalhes sobre os tempos: o navegador consultava o endpoint do tipo /ajax/check_request.php a cada segundo, e o TTL do token para o iframe era de 10 segundos. No entanto, os pesquisadores apontam um erro de implementação: a ausência de controle rígido do tempo máximo de vida permitia falsificar tokens "de longa duração".
Separadamente, o relatório menciona indicadores de "autodefesa" da infraestrutura: 254 registros na lista de bloqueio de IP (incluindo CIDR e endereços pontuais), 49 substrings para bloqueio por ISP/ASN e 16 padrões por user-agent. Essencialmente, isso reflete a maturidade da plataforma de phishing: os atacantes claramente esperavam atenção de provedores, equipes SOC e pesquisadores e construíram filtros antecipadamente contra "visitantes indesejados".
Outro detalhe significativo especificamente para o mercado de frete dos EUA: nos materiais restaurados pelos pesquisadores, aparecem designações de marca internas GlobalProfit e o nome de marketing "MC Profit Always". O relatório sugere que "MC" remete ao número Motor Carrier (MC number) no sistema FMCSA — ou seja, os criadores claramente pensavam em termos do mercado americano e sua identificação habitual de transportadoras.
Os pesquisadores acreditam que a plataforma poderia evoluir para "phishing-as-a-service", ou seja, um produto para venda a outros criminosos: modelos prontos para serviços do setor, painel de controle, bots no Telegram, registro de logs, ban/cloaking, rápida rotação de domínios, além de um modelo operacional para interceptação de MFA.
A resistência dos atacantes era alta, mas, segundo o relatório, eles foram traídos por um erro operacional: em um dos sites de phishing, o diretório .git estava acessível. Isso permitiu que os pesquisadores baixassem o histórico de desenvolvimento e coletassem praticamente todo o rastro de artefatos: base de código, dumps de banco de dados, logs de webhook, fragmentos de comunicações internas e histórico de alterações. O relatório indica que a plataforma restaurada incluía mais de 2.100 arquivos e um banco de dados com 54 tabelas; um artefato chave separado foi um dump SQL de 36,6 MB com marca de tempo de 4 de fevereiro de 2026.
No ferramental do Telegram, segundo os pesquisadores, foram encontrados 10 tokens de bots, dos quais nove permaneciam ativos no momento da análise. Isso é importante para os praticantes: tal esquema de controle vive enquanto os tokens e canais vivem, portanto, o vazamento de tokens pode acelerar o "corte" da infraestrutura, se os provedores os revogarem rapidamente.
Os autores do relatório descrevem o grupo como "relacionado à Rússia": são mencionados comentários em russo no código e na documentação, bem como metadados que indicam um contexto moscovita. Simultaneamente, nos logs do Telegram, segundo eles, há presença do idioma armênio, e o parceiro Ctrl-Alt-Intel participou da interpretação dos fragmentos correspondentes. Isso parece uma equipe operacional mista ou uma distribuição de papéis entre os participantes. Os pesquisadores não nomeiam personalidades reais; aparecem apenas rótulos/papéis de operadores em bots e logs (por exemplo, "Leo operator", "Penske operator"), que não podem ser tratados como identificação de pessoas específicas.
Como não há confirmações independentes de atribuição no momento da publicação, os participantes do mercado devem considerar a "geografia" do grupo como uma hipótese de trabalho dos pesquisadores, e não como um fato estabelecido pelas autoridades.
Mesmo que se exclua o nome específico Diesel Vortex, o próprio modelo de ataque se encaixa bem nos pontos críticos atuais do setor. A recuperação do spot e a luta por margem aumentam a velocidade de tomada de decisões, o que aumenta a vulnerabilidade a e-mails "confirme sua conta urgentemente", "atualize sua senha", "verifique o pagamento". Paralelamente, associações profissionais nos EUA destacam publicamente o aumento dos danos causados pela corretagem dupla e manipulações de pagamento e apoiam o endurecimento das medidas contra fraudes no mercado. Para os atacantes, o roubo de contas para bolsas de carga e sistemas de pagamento é um caminho direto para os mesmos esquemas, só que com uma "conversão" mais alta, porque o acesso parece legítimo.
Na prática, isso significa que para transportadoras e corretores a "porta de entrada" para a maioria das grandes perdas ainda é banal: a conta de um despachante, contador ou proprietário-operador em uma bolsa de carga ou serviço de pagamento, para a qual conseguiram não adivinhar a senha, mas ganhar a confiança do usuário — e interceptar o MFA no momento da entrada.
