Resumo
- Em 2018, ao obter as credenciais de um contratado da British Airways, agentes maliciosos conseguiram modificar um script executado no lado do cliente para exfiltrar dados de cartões de crédito para um endpoint controlado por eles — esse domínio é baways[.]com, que pertence à cside desde 2024.
- No domínio baways[.]com você pode ler, com todos os detalhes, uma linha do tempo objetiva dos eventos e suas consequências.
- Após o incidente, o ICO pretendia multar a British Airways em £183 milhões, mas a multa foi posteriormente reduzida para £20 milhões. Na época, a British Airways enfrentava dificuldades em razão da Covid-19, o que pode ter contribuído para a redução da penalidade.
- Após esse incidente e muitos outros semelhantes, o PCI DSS (Payment Card Industry Data Security Standard) atualizou seus requisitos para incluir monitoramento, proteção e documentação de scripts no lado do cliente.
- Hoje, há mais soluções no mercado para ajudar a prevenir esse tipo de incidente, mas a qualidade das abordagens varia significativamente.
Por que compramos o baways[.]com
Porque podíamos. Surpreendentemente, mesmo que muitos fornecedores falassem sobre o ataque o tempo todo, 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 por meio das páginas de marketing dos fornecedores, o que estava sendo escrito deixou de estar alinhado com os fatos. Por isso, decidimos reunir as evidências, documentos judiciais, comunicados de imprensa e páginas arquivadas uma última vez e publicar tudo em um relatório consolidado. No próprio domínio que foi usado no ataque.
Chegamos até a contratar um ex-jornalista para ajudar na pesquisa.
![Banner do micro-site baways[.]com.](/content/images/2025/12/Screenshot-2025-12-14-at-8.20.04---PM.png)
Linha do tempo do ataque à British Airways:
22 de junho de 2018: Um atacante acessa a rede da British Airways usando 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 vasculha o ambiente. Encontra algo alarmante: credenciais de administrador de domínio armazenadas em texto simples. Simplesmente em um arquivo. Sem criptografia.
26 de julho de 2018: O atacante descobre arquivos de log contendo dados de cartões de pagamento. Também em texto simples. Esses dados vinham de um recurso de teste que nunca deveria ter ido para produção.
21 de agosto a 5 de setembro de 2018: O ataque entra em operação. Por 16 dias, todo cliente que inseriu dados de pagamento no site da BA teve suas informações copiadas e enviadas para baways[.]com.
5 de setembro de 2018: A British Airways é notificada por um terceiro. O ataque é encerrado em 90 minutos.
Como o ataque à British Airways funcionou
O atacante injetou código malicioso no Modernizr, uma biblioteca JavaScript comum que ajuda sites a funcionar em diferentes navegadores. A British Airways estava servindo essa versão comprometida a todos os seus clientes.
- O script malicioso aguardava os clientes clicarem no botão de confirmação do pagamento
- Ele capturava todos os dados de pagamento e informações pessoais do formulário
- Enviava esses dados para baways[.]com (que parecia legítimo, já que a BA usa "BA" em seu marketing)
- Tudo acontecia silenciosamente em segundo plano
- O processo normal de pagamento continuava sem nenhum problema
Por que o ataque à British Airways não foi detectado pela segurança de rede
O ataque aconteceu sem deixar rastros visíveis. A única forma de perceber que algo fora do comum estava ocorrendo era nas ferramentas de desenvolvedor do navegador, na aba de rede, no momento em que os dados eram enviados.
O ataque também afetou o aplicativo móvel, que executava uma webview da aplicação web. A própria webview não tinha painel de ferramentas de desenvolvedor, portanto, no aplicativo móvel absolutamente nenhum rastro visível foi deixado.
Teria sido extremamente difícil, senão impossível, para os clientes perceberem que seus dados estavam sendo roubados.
O impacto
Nos procedimentos judiciais, o ICO (Information Commissioner's Office) divulgou os números completos.
| Categoria | Número de Afetados |
|---|---|
| Dados completos do 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 |
O ICO inicialmente propôs uma multa de £183,39 milhões. Após negociações, o devido processo legal e o escrutínio financeiro causado pela COVID-19 sobre a British Airways, a multa foi reduzida para £20 milhões.
A British Airways sofreu perdas significativas e o CEO da época foi obrigado a pedir desculpas publicamente, garantindo que os clientes afetados seriam compensados.
A multa não é o único impacto financeiro. Diversas ações coletivas se seguiram; fontes públicas estimam danos entre £2.000 e £6.000 por requerente. Com mais de 16.000 vítimas representadas em apenas uma ação judicial, o impacto financeiro total provavelmente superou a multa regulatória, sem nem considerar o impacto comercial do dano à reputação da marca British Airways.
Por que esse incidente ainda importa em 2025
O problema só cresceu. A postura de segurança das aplicações web está centrada em ações voltadas para a infraestrutura web. Novas atenções são dedicadas ao monitoramento de dependências estáticas de código aberto e à adoção de IA nas empresas. Mas desenvolvedores web e equipes de segurança ainda não sabem — nem têm ferramentas confiáveis — para verificar como suas aplicações web e suas dependências, como ferramentas de marketing e pacotes de código aberto, se comportam nos navegadores.
O monitoramento de runtime no lado do cliente teria prevenido o ataque à British Airways
Este é um vetor de ataque altamente dinâmico, portanto a única solução real para a ameaça de segurança é a análise ativa em tempo de execução. A pressão por conformidade regulatória levou algumas empresas a adotar ferramentas de checklist que usam scanners/crawlers ou abordagens sem agente. Essas abordagens são facilmente contornadas pelo agente malicioso, que simplesmente não serve os payloads maliciosos para essas ferramentas.
A segurança real de runtime no lado do cliente ainda não é uma prioridade elevada. Os agentes maliciosos estão cientes disso, com ataques no lado do cliente significativamente complexos acontecendo diariamente. Alguns casos recentes de grande destaque incluem o ataque ao Bybit, o ataque ao CoinMarketCap e o ataque ao Polyfill em 2024, que visou mais de 490.000 sites usando um script semelhante ao Modernizr.
A cadeia de suprimentos no lado do cliente apresenta desafios extras significativos. Cada requisição a um servidor de terceiros pode gerar uma resposta dinâmica e diferente. A análise constante é custosa, mas é a única forma de gerenciar a postura de segurança.
O que mudou após o incidente com a British Airways
Na época do incidente com a British Airways, muitos incidentes semelhantes ocorreram, como a violação do Ticketmaster e o ataque ao Newegg. Mastercard, Visa e American Express divulgaram que a maior quantidade de dados de cartões de crédito é roubada atualmente por meio de scripts maliciosos no lado do cliente. Por isso, a resposta foi ajustar o framework de conformidade PCI DSS para incluir segurança no lado do cliente em 2 novos requisitos de conformidade: 6.4.3 e 11.6.1. Escrevemos um post detalhado sobre eles aqui.
Após o ajuste no PCI DSS, outros frameworks do setor esclareceram seus requisitos em relação à segurança da cadeia de suprimentos para incluir dependências executadas no lado do cliente. Incidentes como o vazamento de dados da Kaiser Permanente desencadearam atualizações na HIPAA.
Está se tornando cada vez mais um requisito básico adotar soluções de segurança de runtime no lado do cliente para monitorar as ações do site. No entanto, cada requisito de conformidade exige evidências em seu próprio formato — alguns mais centrados no uso de cookies, outros mais focados em fluxos de dados. Com uma solução como a cside, porém, isso se torna muito simples.
Como a cside ajuda
A cside oferece uma abordagem altamente flexível para segurança no lado do cliente. Seja monitorando comportamentos de scripts no lado do cliente e analisando os scripts de forma mais aprofundada em nosso ambiente por meio de relatórios no lado do cliente em nosso motor, a cside obtém o quadro completo. Ela analisa o código das dependências servidas em tempo real, ajudando você a evitar que comportamentos indesejados causem grandes impactos nos negócios.
Nossa abordagem nos permite não apenas identificar ataques avançados e altamente direcionados e emitir alertas sobre eles — a cside também torna possível bloquear ataques antes que eles cheguem ao navegador do usuário. Ela também atende aos requisitos de múltiplos frameworks de conformidade, incluindo PCI DSS 4.0.1, HIPAA, GDPR, CPRA... Fornecemos ainda análise forense aprofundada, inclusive quando um atacante tenta contornar nossas detecções. Armazenamos dados sobre ataques não detectados, o que nos permite aprimorar continuamente nossas detecções. Dando a você o controle necessário em um formato fácil de usar. Lidando com as limitações dos navegadores, sabemos que esta é a forma mais segura de monitorar e proteger suas dependências em todo o seu site. Passamos anos no espaço de segurança no lado do cliente antes de fundar a cside. Conhecemos as limitações dos navegadores e investimos tempo contribuindo com organismos de padronização para tornar as capacidades de segurança nativamente suportadas, melhores e mais fáceis de usar.
Cadastre-se ou agende uma demonstração para começar.
O que fazer a partir daqui
Se você ficou intrigado com a história, confira o micro-site interativo em baways[.]com. Fizemos um esforço especial para apresentar a história em um formato atraente — esperamos que você aproveite.
