Um agente malicioso realizou um ataque à cadeia de suprimentos ao comprometer a infraestrutura de domínio que servia o AppsFlyer Web SDK, injetando um payload polimórfico de roubo de criptomoedas em milhares de sites. O ataque contornou controles de segurança ao sequestrar o DNS no nível do registrador, permitindo que os atacantes servissem código malicioso a partir do que parecia ser endpoints legítimos da AppsFlyer. O script injetado substituiu a API nativa window.fetch, monitorou o DOM em busca de endereços de criptomoedas e enviou dados das vítimas para servidores de comando e controle controlados pelos atacantes. O ataque também teve como alvo ambientes de servidor Node.js, expondo frameworks SSR e pipelines de build a riscos.
O que a telemetria da cside mostra
Antes de o incidente ser amplamente conhecido, a telemetria do Script Insights da cside registrou comportamento incomum do AppsFlyer Web SDK. A partir de 1º de março, os sistemas observaram que dois hashes de script diferentes estavam sendo servidos a partir do endpoint oficial da AppsFlyer em toda a rede monitorada. Essa rotação começou antes de o incidente ser confirmado, sugerindo que os atacantes estavam testando sua infraestrutura de implantação ou deliberadamente servindo builds polimórficas para evitar detecção.
A telemetria confirma que grandes plataformas carregaram o SDK comprometido. Domínios específicos estão sendo omitidos enquanto as organizações afetadas concluem a remediação. Para os controles prescritivos que contêm esse tipo de incidente, consulte nossas melhores práticas para proteger scripts de terceiros contra comprometimentos da cadeia de suprimentos.
O vetor de entrada: um sequestro de DNS no nível do registrador
Os atacantes não violaram a infraestrutura AWS da AppsFlyer nem seus repositórios internos. Eles obtiveram controle por meio de um sequestro de DNS no nível do registrador.
Ao comprometer a conta do registrador de domínio do appsflyer.com, os atacantes alteraram seus nameservers autoritativos. Os registros de DNS mostram que, no início do ataque, os nameservers do appsflyer.com mudaram do AWS Route 53 para ns1.gcorelabs.net (GCore CDN).
Com o controle do DNS, os atacantes rotearam todo o tráfego de websdk.appsflyer.com por seus próprios servidores. Eles interceptaram as requisições ao SDK legítimo e entregaram um payload malicioso e rebaixado. Como o comprometimento ocorreu na camada de DNS, esse método contornou as defesas de perímetro padrão e as proteções do lado do servidor.
O principal indicador forense: um downgrade silencioso de versão
Como os atacantes controlavam o DNS, eles não alteraram a lógica central do SDK da AppsFlyer — apenas o utilizaram para entregar seu payload.
O sinal mais claro de adulteração foi um downgrade silencioso de versão. O SDK de referência antes do incidente era a versão 0.0.60 (hash 7dbae31c...). Durante o ataque, a versão servida a partir do endpoint oficial reverteu para 0.0.59 (hash db0c4f61...). Atualizações legítimas não retrocedem números de versão, o que torna isso uma evidência clara de adulteração.
Ao comparar os SDKs limpo e rebaixado, foram identificadas três linhas modificadas. Os atacantes removeram endpoints específicos de banner e alteraram a string de versão interna.
// SDK limpo (0.0.60)
VERSION:"0.0.60"
banner.appsflyer.com/
banner.appsflyer.com/sb/
dismissInjectPixel // presente na build limpa
// SDK comprometido (0.0.59)
VERSION:"0.0.59"
banner.appsflyer.com/ // endpoint .sb/ removido
// função dismissInjectPixel removida
Os atacantes evitaram alterar fvalid.appsflyer[.]com ou wa.appsflyer[.]com/events, o que teria quebrado as verificações de Subresource Integrity. Em vez disso, usaram o sequestro de DNS para rotear todo o tráfego do appsflyer.com por sua infraestrutura, onde os payloads maliciosos eram servidos.
Após o ataque, a AppsFlyer migrou sua infraestrutura para appsflyersdk[.]com e lançou uma build limpa 0.0.61 nesse domínio. O domínio appsflyersdk[.]com, registrado em agosto de 2019, pertence à AppsFlyer.
Desofuscando os payloads polimórficos
O tráfego roteado pelos servidores comprometidos carregava o payload de roubo de criptomoedas. A análise de três arquivos maliciosos revelou uma abordagem de implantação polimórfica com dois esquemas de ofuscação direcionados a ambientes de execução distintos.
Tipo de build 1: o payload para navegador (c7adfa8e)
O primeiro payload, com cerca de 170KB, é executado no escopo global window do navegador. Ele usa codificação base91 personalizada com um alfabeto de 83 caracteres para decodificar uma tabela de strings com 786 entradas em tempo de execução.
Em um sandbox, esse payload substitui o window.fetch e registra um MutationObserver para varrer o DOM em busca de endereços de criptomoedas. Ele também adiciona um módulo interno chamado NetHooksmith ao objeto window (window.lIXMkR.NetHooksmith).
Tipo de build 2: os wrappers Node.js (87e46457 & 9b0fac22)
A segunda variante, encontrada em duas builds de cerca de 250KB cada, usa uma técnica de ofuscação diferente voltada para ambientes de servidor. Em vez de base91, esses arquivos encapsulam a lógica central em construtores Function() aninhados e decodificam strings por meio de um array de constantes rotativo combinado com String.fromCodePoint.
Esses wrappers usam objetos getter para se conectar a contextos Node.js: por exemplo, get GKSDgsL(){return global} e get F1t0ak(){return exports}. Aplicações Node.js, frameworks SSR e pipelines de build que importaram o SDK via npm ou bundlers eram suscetíveis.
Ao interceptar chamadas de fromCodePoint durante a execução no sandbox, as strings decodificadas foram obtidas. Elas confirmaram que os wrappers executavam a mesma lógica central de substituição do fetch, mas usavam endereços de carteiras separados, evidenciando infraestrutura dedicada para o comprometimento do lado do servidor.
Os dois clusters de carteiras e a infraestrutura de C2
A análise em sandbox identificou dois clusters distintos de carteiras dos atacantes. O payload para navegador (Tipo de build 1) continha um conjunto de endereços, e os payloads Node.js (Tipo de build 2) continham outro. Ambos armazenavam esses dados em um objeto global walletAddresses.
Cluster 1 (payload para navegador c7adfa8e)
- ETH:
0x1C069d0c73087D0Bae687a6f74a807350dCe1829 - BTC:
bc1qr7ngtnsh66demm4vzt4kmqxkqj8sqprnuklalt - SOL:
4LJi6mAczxZWbUvbMEk5scKhUZNPvfMDTjaVADkPFSsK - XRP:
rntqwheGbZihkabxf6xqZkUKGfTVyRhT14 - TRX:
TV6WtAkS4aAMJb3Rt2bfs8LxggF8Kmqbd9
Cluster 2 (wrappers Node.js 87e46457 & 9b0fac22)
- ETH:
0x782B93e52e62F25Bd002eeAA813B5A3fe49C9558 - BTC:
bc1q5nlx0exu0efldavw08wnjzpzluudaqh2qwlmjj - SOL:
B5hMeV7B72xqcjypzxxoPmLpNz3bi6VvZApQrnh8YwDP - XRP:
rEL7cB3jQNqtoym8oFJ36w1z3QLy9GjU - TRX:
T062f95a517fc05055b59e12c6f4b2a402
Endpoints de comando e controle (C2)
Os payloads se comunicavam com dois endpoints de C2 na infraestrutura sequestrada:
https://websdk[.]appsflyer[.]com/v1/api/plugin- buscava novos endereços de carteiras na inicialização.https://websdk[.]appsflyer[.]com/v1/api/process- enviava endereços de carteiras exfiltrados e metadados usando um parâmetro de consulta?rd=contendo dados ofuscados por XOR.
Assinaturas comportamentais e detecção
Como os atacantes rotacionaram esquemas de ofuscação e endereços de carteiras, assinaturas estáticas como regras YARA foram ineficazes. O comportamento dos payloads, no entanto, é consistente e pode ser detectado.
As equipes de segurança devem procurar pelos seguintes indicadores:
- Saída no console: Todos os payloads imprimem "Generating new wallets..." no console durante a inicialização.
- Substituição do
fetch: O payload sobrescreve a API nativafetchpara interceptar requisições de saída com endereços de criptomoedas. - Poluição de objeto global: O payload cria um objeto global
walletAddresses; a variante para navegador adicionawindow.lIXMkR.NetHooksmith. - Supressão do console: O payload para navegador usa 32 referências a métodos de
consolepara ocultar avisos e erros. - Rastreamento de mutações no DOM: O payload para navegador registra um
MutationObserverpara varrer novos elementos do DOM em busca de padrões de endereços de criptomoedas.
Além do incidente: a superfície de fingerprinting do SDK legítimo
A revisão do SDK limpo (hash 7dbae31c) revelou que o plugin PBA legítimo da AppsFlyer coletava dados extensos de fingerprinting de dispositivos, incluindo verificações de fontes via canvas, detecção de bloqueadores de anúncios, detecção de bots e acesso a localStorage, sessionStorage e indexedDB.
O SDK também carrega código adicional de fvalid.appsflyer[.]com/af/cp.sdk.1.2.7.js em tempo de execução. Embora comum em SDKs de marketing, isso representa um risco contínuo à cadeia de suprimentos. As organizações devem avaliar a necessidade desse tipo de rastreamento e aplicar Content Security Policies (CSP) e Subresource Integrity (SRI) rigorosas a todo código de terceiros.
Como a cside poderia ter ajudado
Um sequestro de domínio no nível do registrador contorna defesas de perímetro e análise estática. A abordagem de segurança client-side da cside detecta e bloqueia esse tipo de ataque em tempo real por meio dos seguintes mecanismos:
- Detecção de anomalias comportamentais: A cside monitora as ações dos scripts em vez de assinaturas estáticas, emitindo alertas sobre tentativas de sobrescrever o
window.fetchou acessar entradas de criptomoedas. - Bloqueio de exfiltração de rede: Se o payload for executado, os controles de rede da cside podem bloquear conexões de saída para servidores de C2, impedindo a recuperação de carteiras e o roubo de dados.
- Alertas de rotação de hash: A telemetria da cside detectou hashes de script alternados dias antes de o ataque se tornar público, permitindo investigação antecipada.
- Detecção de downgrade de versão: A cside registra versões e hashes exatos de scripts de terceiros. Um downgrade silencioso de
v0.0.60parav0.0.59acionaria um alerta imediato de adulteração.
Ao aplicar medidas de zero trust no lado do cliente, a cside impede que scripts de fornecedores comprometidos explorem a confiança dos usuários.
Indicadores de comprometimento (IOCs)
- Domínio:
appsflyer[.]com- Domínio legítimo sequestrado no nível do registrador - Nameserver:
ns1.gcorelabs.net- Nameserver controlado pelos atacantes durante o sequestro - URL (C2):
https://websdk[.]appsflyer[.]com/v1/api/plugin- Endpoint de C2 do payload (rotação de carteiras) - URL (C2):
https://websdk[.]appsflyer[.]com/v1/api/process- Endpoint de C2 do payload (exfiltração) - Parâmetro de URL:
?rd=- Contém dados de exfiltração ofuscados por XOR - Carteira (ETH):
0x1C069d0c73087D0Bae687a6f74a807350dCe1829- Cluster 1 (payload para navegador) - Carteira (BTC):
bc1qr7ngtnsh66demm4vzt4kmqxkqj8sqprnuklalt- Cluster 1 (payload para navegador) - Carteira (SOL):
4LJi6mAczxZWbUvbMEk5scKhUZNPvfMDTjaVADkPFSsK- Cluster 1 (payload para navegador) - Carteira (ETH):
0x782B93e52e62F25Bd002eeAA813B5A3fe49C9558- Cluster 2 (wrappers Node.js) - String no console: "Generating new wallets..." - Saída em texto simples por todos os payloads
- Objeto global:
walletAddresses- Injetado por todas as variantes de payload - Objeto global:
window.lIXMkR.NetHooksmith- Injetado pelo payload para navegador - String de versão:
0.0.59- Versão rebaixada do SDK indicando adulteração
Recomendações
- Compare imediatamente a versão e o hash do SDK servido por qualquer endpoint da AppsFlyer que você consome com hashes conhecidos como válidos; trate downgrades silenciosos como alertas de adulteração de alta prioridade.
- Bloqueie ou redirecione para sinkhole as requisições de saída para os endpoints de C2 identificados e os nameservers associados até que a remediação seja concluída.
- Reforce a CSP e aplique SRI para recursos de terceiros sempre que possível; considere hospedar localmente scripts críticos de fornecedores após verificar a integridade.
- Verifique pipelines de build do lado do servidor e implantações SSR em busca dos indicadores de wrapper Node.js descritos acima e rotacione quaisquer credenciais afetadas.
- Implante a cside para monitorar substituições de API (como
fetch) e varredura de mutações no DOM por scripts de terceiros.
Este incidente não é um caso isolado. Para uma análise mais aprofundada de como a lavagem de infraestrutura estende a ameaça para além do comprometimento de um único fornecedor, consulte nossa análise da infraestrutura de polyfills sancionada.
Detalhes forenses, hashes de arquivos e telemetria adicional estão disponíveis mediante solicitação para organizações afetadas e respondentes a incidentes.
Nota: Esta publicação resume as descobertas da telemetria do Script Insights da cside e da análise em sandbox. Alguns domínios específicos e IOCs adicionais estão sendo omitidos enquanto as partes impactadas realizam a remediação.
