Se você já viveu com medo de ser hackeado e seus fundos desviados por um ator malicioso, a empresa líder em segurança de blockchain Certora tentou aliviar esses medos na quinta-feira, 12 de fevereiro, por meio de uma transmissão ao vivo intitulada "Como os Hacks DeFi mudaram nos últimos 5 anos e o que isso significa para os protocolos".
O CEO da Certora, Seth Hallem, juntou-se a Ofek Ray Orlev, um investigador de segurança sénior e chefe de equipa da empresa, para analisar como os ataques modernos diferem das explorações DeFi anteriores e o que as equipas de protocolo devem fazer em resposta.
Seth juntou-se à Certora há oito meses, depois de construir uma carreira em análise estática, qualidade de software e cibersegurança. Ele agora aplica essa experiência ao Web3 e ao DeFi. Ofek traz doze anos de experiência em investigação de vulnerabilidades em domínios ofensivos e defensivos. Antes de entrar no espaço DeFi há dois anos, liderou esforços de red teaming e testes de penetração na Intel, onde desenvolveu ferramentas ofensivas e defensivas para sistemas incorporados.
Em vez de revisitar hacks bem conhecidos, a discussão centrou-se em dois ataques recentes e sofisticados. O primeiro, CPIMP, significa Clandestine Proxy In The Middle of Proxy (Proxy Clandestino no Meio do Proxy). O segundo, GlassWorm, representa o primeiro worm de auto-propagação direcionado à criptografia a atacar a cadeia de suprimentos do NPM e do OpenVSX. Juntos, estes ataques ilustram como a segurança DeFi passou de bugs óbvios para campanhas sistémicas, pacientes e com várias camadas.
Ataque de proxy clandestino no meio do proxy (CPIMP)
O ataque CPIMP explora padrões de inicialização de proxy em contratos inteligentes. Em sua essência, o ataque sequestra a fase de inicialização de um contrato de proxy. Se um invasor executar a primeira chamada de inicialização, ele poderá inicializar o proxy com uma implementação maliciosa.
O que torna o CPIMP particularmente notável não é apenas a sua posição inicial, mas também a persistência e a furtividade que se seguem. O proxy malicioso imita a implementação pretendida, pelo que todos os testes e interações normais continuam a passar. Os programadores e os utilizadores não vêem qualquer anomalia óbvia. O atacante insere um proxy clandestino entre o proxy legítimo e a sua lógica pretendida, o que lhe permite intercetar e manipular chamadas sem deteção imediata.
Os agentes maliciosos também criaram a persistência através de actualizações. Quando os programadores actualizam o proxy para acrescentar funcionalidades, a camada maliciosa reinjecta o seu código na nova implementação. Uma vez infetada, cada atualização subsequente passa pelo pipeline do atacante. Esta conceção permite um controlo a longo prazo em vez de uma exploração rápida.
Os atacantes chegaram mesmo a explorar uma vulnerabilidade no Etherscan que lhes permitiu falsificar o endereço da implementação apresentada, preenchendo uma ranhura de armazenamento desactualizada. Observadores externos que dependem de exploradores de blocos veriam a implementação errada, obscurecendo ainda mais a deteção.
Seth e Ofek compararam esta abordagem a uma "puxada de tapete", mas enfatizaram um horizonte de tempo diferente. Uma puxada de tapete tradicional geralmente drena fundos rapidamente. O CPIMP parece ter sido concebido para esperar até que um protocolo cresça o suficiente para justificar a sua ativação. O atacante pode tratar o sistema comprometido como um ativo adormecido que amadurece com o tempo. Essa paciência sugere uma mentalidade de campanha em vez de uma exploração oportunista.
Ataque GlassWorm: Extração de chaves privadas de 50 extensões de carteiras
O GlassWorm desloca o campo de batalha da lógica onchain para a cadeia de fornecimento de desenvolvimento. Os atacantes introduziram uma extensão maliciosa do VS Code que infectou as máquinas dos programadores. Uma vez instalada, a extensão extraía chaves privadas de aproximadamente cinquenta extensões de carteiras. Também procurava credenciais GitHub e determinava se o programador infetado mantinha outras extensões VS Code.
Se o programador publicasse uma extensão, o worm injectava código malicioso nessa extensão antes da distribuição. Este mecanismo de propagação transformou o malware num verdadeiro worm. Cada extensão recém-infetada espalha o payload ainda mais, ampliando o seu alcance através do ecossistema.
Tire um segundo para compreender esta informação. O utilizador é um programador. A sua máquina é infetada. Provavelmente, os seus fundos são drenados. Todas as extensões que desenvolve são infectadas e todos os que as descarregam também são infectados, e assim por diante.
O rótulo "glass" refere-se à utilização de caracteres não imprimíveis para esconder código malicioso. O payload aparecia como linhas em branco ou espaços em branco nos editores. As ferramentas tradicionais de análise estática não conseguiram detetar o código antes de os investigadores identificarem o ataque.
O GlassWorm combinou técnicas conhecidas com inovações. Reutilizou estratégias estabelecidas de comprometimento da cadeia de fornecimento e métodos de extração de chaves privadas. No entanto, introduziu um novo mecanismo de comando e controlo, aproveitando a cadeia de blocos Solana. O worm lia instruções encriptadas incorporadas nos campos de notas de transação. Como os atacantes assinavam essas transacções com a sua própria carteira, as máquinas infectadas podiam verificar e executar novas instruções sem depender de um servidor tradicional.
Esta conceção de comando e controlo onchain dificultou muito os esforços de captura. As equipas de segurança ou de aplicação da lei não podiam simplesmente apreender um servidor centralizado. Os atacantes também usaram assuntos de eventos do Google Calendar como um canal de comunicação de backup. Essas camadas criaram resiliência e flexibilidade que os pesquisadores de segurança raramente observam em worms Web2 anteriores.
O worm também instalou um cliente VNC oculto e configurou um proxy SOCKS nas máquinas infectadas. Estas capacidades indicam que os atacantes procuravam mais do que o roubo de carteiras. O seu objetivo era obter um acesso alargado aos sistemas das vítimas. O ataque obscureceu a linha entre Web2 e Web3 e demonstrou que a segurança DeFi não pára mais em contratos inteligentes.
O que você pode fazer para se proteger?
Ambos os palestrantes enfatizaram que os desenvolvedores não devem adotar uma mentalidade niilista. A segurança perfeita não existe, mas as melhorias práticas reduzem significativamente o risco.
Ofek aconselhou as equipes a examinar suas cadeias de ferramentas, limitar extensões desnecessárias e manter as dependências atualizadas. Ele pediu aos desenvolvedores que realmente entendam como seus processos de implantação são executados.
Ele também recomendou a verificação pós-implantação. As equipes devem inspecionar os slots de armazenamento onchain diretamente, em vez de confiar apenas nos exploradores de blocos. Eles devem confirmar que nenhuma chamada de delegação inesperada ou etapas de inicialização ocorreram.
Seth enfatizou o pensamento arquitetônico. Ele afirmou: "a ideia de que uma extensão de navegador é um lugar seguro para descriptografar uma chave privada e assinar transações que movimentam dinheiro é um conceito falho construído a partir do modelo de ameaça errado." Ele argumentou que as extensões de navegador são executadas em ambientes altamente dinâmicos e não devem lidar com operações criptográficas de alto valor. Os módulos de segurança de hardware e os ambientes de assinatura isolados oferecem maiores garantias.
Mert Mumtaz, CEO da Helius Labs, fez eco desse sentimento num post público, escrevendo que a ideia de que as carteiras são extensões do Chrome representa uma das decisões UX mais questionáveis da indústria.
Ambas as perspectivas destacam a necessidade de repensar os pressupostos de segurança das carteiras à medida que os fluxos de capital aumentam.
A que é que devemos estar atentos em 2026?
Olhando para 2026, ambos os oradores esperam uma maior participação institucional na Web3. À medida que os governos e as grandes instituições financeiras avaliam um envolvimento mais profundo, os protocolos enfrentarão requisitos mais rigorosos de due diligence e conformidade. Documentação, verificação formal, procedimentos padronizados e parcerias de segurança contínuas provavelmente se tornarão expectativas básicas.
No lado ofensivo, os atacantes continuarão a misturar técnicas Web2 e Web3. À medida que a qualidade dos contratos inteligentes melhora e as auditorias se tornam mais comuns, os atacantes terão como alvo a engenharia social, a exfiltração de chaves privadas, os frontends, os processos de governação e as cadeias de fornecimento. Seth comparou essa mudança com o aumento do ransomware na Web2 depois que as organizações fortaleceram os serviços expostos.
Os protocolos devem esperar que os atacantes se comportem como empresas. Algumas campanhas procurarão obter ganhos transaccionais, como o phishing e o roubo de carteiras. Outras procurarão oportunidades estratégicas que visem fraquezas sistémicas em infra-estruturas de triliões de dólares.
Reflexões finais
A transmissão ao vivo destacou uma clara mudança na segurança DeFi. As primeiras explorações baseavam-se frequentemente em erros óbvios de codificação. Os ataques modernos funcionam com paciência, persistência e sofisticação entre domínios. O CPIMP demonstrou como os atacantes se podem esconder dentro de arquitecturas proxy e esperar que o valor se acumule. O GlassWorm mostrou como os comprometimentos da cadeia de fornecimento e o comando e controlo na cadeia podem estender-se para além dos contratos inteligentes em ambientes de programadores.
Os protocolos não podem prever todas as técnicas futuras. Eles podem, no entanto, aumentar o custo do ataque por meio de arquitetura disciplinada, implantação cuidadosa, superfícies de ameaça minimizadas e verificação contínua. À medida que o capital e o escrutínio regulatório aumentam, a segurança passará de uma auditoria pontual para um requisito operacional contínuo.
Leia mais sobre o SolanaFloor
Os desenvolvedores em Solana aumentam quase 10 vezes desde 2020, já que a rede recebe um recorde de 3830 novos desenvolvedores em 2025
Solana Perps Scene Snubbed mais uma vez como Trojan Terminal integra-se em outro lugar
Os títulos do Tesouro de ativos digitais podem sobreviver ao crash?
