Resumo: análise do skimmer Modernizr de 22 linhas da British Airways
- cside detém baways[.]com: A multa de £183 milhões foi a manchete, mas o verdadeiro escândalo foi que a cside comprou o domínio do atacante, baways[.]com, por $10 depois de ele expirar. Ninguém nos fornecedores que citam a BA em todas as apresentações se deu ao trabalho de fazer o mesmo.
- A dimensão: O ataque durou 16 dias e expôs 429.612 pessoas, incluindo 244.000 registos completos de cartão e 77.000 com CVV, através de um ficheiro Modernizr modificado. A cside monitoriza o que os scripts de terceiros realmente fazem em tempo de execução, exatamente aquilo que a ICO disse que a BA não conseguia ver.
- Adicione monitorização de comportamento: Se as suas páginas de pagamento carregam qualquer JS de terceiros, adicione monitorização contínua de comportamento para os requisitos 6.4.3 e 11.6.1 do PCI DSS ainda este trimestre. Se não conseguir, reduza as páginas de pagamento apenas aos scripts essenciais antes da próxima auditoria.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Resumo
- Em 2018, ao obter as credenciais de um contratado da British Airways, agentes maliciosos conseguiram alterar um script executado no lado do cliente para exfiltrar dados de cartões de crédito para um endpoint controlado por esses agentes; esse domínio é o baways[.]com, que pertence à cside desde 2024.
- No domínio baways[.]com pode ler-se, com todo o pormenor, uma cronologia objetiva dos acontecimentos e das suas consequências.
- Na sequência do incidente, a ICO pretendia multar a British Airways em £183 milhões, mas a multa foi posteriormente reduzida para £20 milhões. Na altura, a British Airways enfrentava dificuldades devido à Covid-19, o que pode ter contribuído para a redução da multa.
- Na sequência do incidente e de muitos ataques semelhantes, o PCI DSS (Payment Card Industry Data Security Standard) atualizou os seus requisitos para incluir a monitorização, proteção e documentação de scripts no lado do cliente.
- Atualmente, existem mais soluções no mercado para ajudar a prevenir este tipo de incidente, mas a qualidade das abordagens varia significativamente.
Porque compramos o baways[.]com
Porque pudemos. Surpreendentemente, apesar de muitos fornecedores falarem constantemente sobre o ataque, o domínio utilizado no ataque expirou e ficou disponível para venda no mercado público pela taxa padrão da ICANN de $10,44 por ano.
Ao longo dos anos, e através das páginas de marketing de vários fornecedores, o que estava a ser escrito deixou de corresponder aos factos, pelo que decidimos reunir, uma última vez, as provas, os documentos judiciais, os comunicados de imprensa e as páginas arquivadas, e publicar tudo num relatório consolidado. No próprio domínio que foi utilizado no ataque.
Chegámos mesmo a contratar um ex-jornalista para ajudar na investigação do tema.
![Banner do micro-site baways[.]com.](/content/images/2025/12/Screenshot-2025-12-14-at-8.20.04---PM.png)
Cronologia do ataque à British Airways:
22 de junho de 2018: Um atacante entra na rede da British Airways utilizando credenciais roubadas de um funcionário da Swissport (uma contratada de serviços de carga). A conta não tinha autenticação multifator.
23 a 26 de junho de 2018: O atacante explora o ambiente. Encontra algo alarmante: credenciais de administrador de domínio armazenadas em texto simples. Simplesmente guardadas num ficheiro. Sem encriptação.
26 de julho de 2018: O atacante descobre ficheiros de registo (logs) contendo dados de cartões de pagamento. Também em texto simples. Estes dados provinham de uma funcionalidade de teste que nunca deveria ter entrado em produção.
21 de agosto a 5 de setembro de 2018: O ataque propriamente dito entra em atividade. Durante 16 dias, todos os clientes que introduziram dados de pagamento no site da BA tiveram os seus dados copiados e enviados para baways[.]com.
5 de setembro de 2018: A British Airways é notificada por terceiros. O ataque é encerrado em 90 minutos.
Como funcionou o ataque à British Airways
O atacante injetou código malicioso no Modernizr, uma biblioteca JavaScript comum que ajuda os sites a funcionar em diferentes navegadores. A British Airways estava a servir esta versão comprometida a todos os seus clientes.
- O script malicioso aguardava que os clientes clicassem no botão de confirmação de pagamento
- Recolhia todos os dados de pagamento e pessoais do formulário
- Enviava esses dados para baways[.]com (que parecia legítimo, uma vez que a BA usa "BA" no seu marketing)
- Tudo acontecia silenciosamente em segundo plano
- O processo normal de pagamento continuava sem qualquer problema
Por que motivo o ataque à British Airways passou despercebido à segurança de rede
O ataque ocorreu sem deixar quaisquer vestígios visíveis. A única forma de detetar que algo fora do comum estava a acontecer era através das ferramentas de programador do navegador, no separador de rede, no momento em que os dados eram enviados.
Este ataque também afetou a aplicação móvel, que executava uma webview da aplicação web. A própria webview não dispunha de um painel de ferramentas de programador, pelo que, na aplicação móvel, não ficou absolutamente nenhum vestígio visível.
Teria sido extremamente difícil, senão impossível, para os clientes detetarem que os seus dados estavam a ser roubados.
Os danos
No âmbito do processo judicial, a ICO (Information Commissioner's Office) divulgou os números completos.
| Categoria | Número de Afetados |
|---|---|
| Dados completos de cartão expostos | 244.000 |
| Cartão + CVV expostos | 77.000 |
| Apenas números de cartão | 108.000 |
| Contas do BA Executive Club | 612 |
| Total de pessoas afetadas | 429.612 |
A ICO propôs inicialmente uma multa de £183,39 milhões. Após negociações, o devido processo e o escrutínio financeiro provocado pela COVID-19 na British Airways, a multa foi reduzida para £20 milhões.
A British Airways sofreu perdas significativas e o CEO da altura foi obrigado a pedir desculpas publicamente, garantindo que os clientes afetados seriam indemnizados.
A multa não é o único impacto financeiro. Seguiram-se múltiplas ações coletivas; fontes públicas estimam danos entre £2.000 e £6.000 por reclamante. Com mais de 16.000 vítimas representadas apenas numa dessas ações, o impacto financeiro total provavelmente superou a multa regulatória, mesmo ignorando o impacto comercial da confiança abalada na marca British Airways.
Por que este incidente ainda é relevante em 2025
O problema só cresceu. As posturas de segurança das aplicações web continuam centradas em ações voltadas para a infraestrutura web. Investe-se cada vez mais atenção na monitorização de dependências estáticas de código aberto e na adoção de IA nas empresas. Mas os programadores web e as equipas de segurança continuam sem saber, nem dispõem de ferramentas fiáveis para verificar, como as suas aplicações web e as respetivas dependências, como ferramentas de marketing e pacotes de código aberto, se comportam nos navegadores.
A monitorização em tempo de execução no lado do cliente teria evitado o ataque à British Airways
Trata-se de um vetor de ataque altamente dinâmico, pelo que a única solução real para esta ameaça de segurança é a análise ativa em tempo de execução. A pressão da conformidade regulatória levou algumas empresas a adotar ferramentas de verificação superficial que utilizam scanners/crawlers ou abordagens sem agente. Estas são facilmente contornadas pelo agente malicioso, que simplesmente não serve os payloads maliciosos a essas ferramentas.
A segurança real de tempo de execução no lado do cliente continua a não ser uma prioridade elevada. Os agentes maliciosos estão cientes disso, com ataques significativamente complexos no lado do cliente a acontecer diariamente. Alguns casos recentes de grande destaque incluem o ataque à Bybit, o ataque ao CoinMarketCap e o ataque ao Polyfill de 2024, que visou mais de 490.000 sites utilizando um script semelhante ao Modernizr.
A cadeia de fornecimento no lado do cliente apresenta desafios adicionais significativos. Cada pedido a um servidor de terceiros pode gerar uma resposta dinâmica e diferente. A análise constante tem custos, mas é a única forma de gerir a postura de segurança.
O que mudou depois do incidente com a British Airways
Por volta da altura do incidente com a British Airways, ocorreram muitos incidentes semelhantes, como a violação da Ticketmaster e o ataque à Newegg. A Mastercard, a Visa e a American Express divulgaram que a maior parte dos dados de cartões de crédito é atualmente roubada através de scripts maliciosos no lado do cliente. Por isso, a resposta passou por ajustar o quadro de conformidade PCI DSS, incluindo a segurança no lado do cliente em 2 novos requisitos de conformidade: 6.4.3 e 11.6.1. Escrevemos um artigo detalhado sobre estes requisitos aqui.
Na sequência do ajuste no PCI DSS, outros quadros de referência do setor clarificaram os seus requisitos relativamente à segurança da cadeia de fornecimento, passando a incluir dependências executadas no lado do cliente. Incidentes como a fuga de dados da Kaiser Permanente motivaram atualizações na HIPAA.
Adotar soluções de segurança de tempo de execução no lado do cliente para monitorizar as ações do site está a tornar-se cada vez mais um requisito básico; no entanto, cada requisito de conformidade exige provas no seu próprio formato. Alguns mais centrados no uso de cookies, outros mais focados nos fluxos de dados. Com uma solução como a cside, porém, isto torna-se extremamente simples.
Como a cside ajuda
A cside oferece uma abordagem altamente flexível à segurança no lado do cliente. Quer monitorizemos os comportamentos dos scripts no lado do cliente, quer verifiquemos os scripts de forma mais aprofundada do nosso lado através de relatórios no lado do cliente no nosso motor, a cside obtém sempre o panorama completo. Analisa em tempo real o código das dependências servidas e ajuda a evitar que comportamentos indesejados causem grandes impactos no negócio.
A nossa abordagem deteta ataques avançados e altamente direcionados e emite alertas sobre eles, e a cside também consegue bloquear ataques antes de estes chegarem ao navegador do utilizador. Também cumpre os requisitos de múltiplos quadros de conformidade, incluindo PCI DSS 4.0.1, HIPAA, GDPR, CPRA... Fornecemos ainda análise forense aprofundada, inclusive quando um atacante tenta contornar as nossas deteções. Guardamos também dados sobre ataques não detetados, o que nos ajuda a melhorar continuamente as deteções e concede o controlo necessário, num formato fácil de utilizar. Lidando com as limitações dos navegadores, sabemos que esta é a forma mais segura de monitorizar e proteger as suas dependências em todo o seu site. Passámos anos no espaço da segurança no lado do cliente antes de fundarmos a cside. Conhecemos as limitações dos navegadores e investimos tempo a contribuir para organismos de normalização, para tornar as capacidades de segurança nativamente suportadas melhores e mais fáceis de usar.
Registe-se ou marque uma demonstração para começar.
O que fazer a partir daqui
Se ficou intrigado com a história, explore o micro-site interativo em baways[.]com. Fizemos os possíveis e o impossível para trazer esta história num formato apelativo; esperamos que goste.
