iFood, Keeta e espionagem corporativa: o risco não estava só no sistema

04/06/2026 - ⧖ 6 min
🗒️

TL;DR: O caso iFood x Keeta mostra uma superfície de ataque que muita empresa ainda trata como problema de RH: abordagem de funcionários, entrevistas remuneradas, vazamento de contexto operacional e metadados de reunião. Para segurança, isso é insider threat, OSINT e proteção de informação sensível.

A história é simples de entender e difícil de controlar.

Segundo reportagens publicadas em maio de 2026, o iFood entrou com ação contra a Keeta, controlada pela Meituan, acusando a rival de concorrência desleal e suposta espionagem corporativa no mercado brasileiro de delivery. A Keeta nega as acusações e afirma operar em conformidade com a legislação local.

O ponto deste texto não é julgar o processo. É olhar para o caso como profissional de segurança.

Porque, se as alegações forem verdadeiras, a parte mais interessante não é "hackearam um sistema". É o contrário: a informação teria saído por conversas, abordagens, incentivos financeiros e rastros de metadados.

A superfície de ataque era gente

O iFood afirma que consultorias abordaram funcionários para obter informações estratégicas e confidenciais em troca de remuneração. A CNN Brasil/Reuters reportou que a ação menciona abordagens a empregados e reuniões para obter dados internos sobre o negócio.

O UOL/Estadão reportou que a acusação fala em dezenas de consultorias e cerca de 140 funcionários abordados. Outras reportagens mencionam números ainda maiores em apurações relacionadas.

Na prática, isso é engenharia social corporativa.

Não é o phishing clássico com boleto falso. É uma mensagem educada no LinkedIn, uma consultoria com nome plausível, uma proposta de entrevista remunerada e perguntas que começam genéricas até encostar em operação interna.

O erro comum é tratar isso como "funcionário não pode falar". A leitura de segurança é mais madura: se a empresa não define claramente o que é informação sensível, alguém vai decidir sozinho no meio de uma call.

O dinheiro muda o modelo de ameaça

Quando uma pessoa recebe uma proposta de conversa remunerada, o risco deixa de ser só técnico.

Você não está defendendo apenas banco de dados, API ou pipeline. Você está defendendo contexto operacional:

  • volume de pedidos;
  • métricas de praça;
  • estratégia de expansão;
  • indicadores de churn;
  • preço, subsídio e margem;
  • arquitetura logística;
  • planos de produto;
  • dados sobre parceiros e restaurantes.

Muita coisa nessa lista talvez não pareça "segredo" isoladamente. O problema é composição. Um atacante ou concorrente não precisa de uma planilha completa se consegue juntar dezenas de pequenas respostas de várias pessoas.

Essa é uma lógica muito parecida com CTI: informação fragmentada ganha valor quando entra em contexto.

Metadado também é evidência

Um ponto forte do caso, segundo reportagens, é que o iFood teria usado registros de videoconferência para ligar participantes a domínios associados à Meituan. O Migalhas reportou que o iFood menciona uma ação de produção antecipada de provas nos Estados Unidos contra a Zoom para obter registros técnicos das reuniões.

Minha leitura aqui: metadado é subestimado.

Mesmo sem o conteúdo completo da conversa, registros como e-mail, domínio, horário, participantes e recorrência podem contar uma história. Em investigação, isso fecha lacunas. Em defesa, isso ajuda a detectar padrão.

Para segurança corporativa, logs de colaboração não são só auditoria burocrática. Eles podem ser a diferença entre "achamos estranho" e "temos uma linha do tempo".

LinkedIn virou canal de ataque

Em outubro de 2025, o CEO do iFood já havia falado publicamente sobre um suposto ataque coordenado, com abordagens via LinkedIn e e-mail corporativo mirando áreas como negócios, tecnologia e comercial, segundo reportagem do iG.

Isso importa porque LinkedIn é onde muita informação sensível começa a vazar sem parecer vazamento.

Cargo, projeto, stack, área, senioridade, mudança de time, contratação recente, expansão de operação. Tudo isso ajuda alguém a escolher alvo, linguagem e pretexto.

Na prática, eu olharia para LinkedIn como parte do perímetro de OSINT da empresa. Não para proibir todo mundo de postar, mas para educar sobre o que não precisa estar público.

O que um time de segurança deveria fazer

Um checklist mínimo seria:

  1. Classificar informação de negócio. Nem todo dado sensível é dado pessoal ou segredo técnico.
  2. Treinar cenários reais. Simular abordagem de consultoria, entrevista remunerada e pedido de "benchmark de mercado".
  3. Criar canal simples de reporte. Se o funcionário recebeu uma proposta estranha, reportar precisa ser fácil e sem medo.
  4. Mapear grupos mais expostos. Produto, dados, estratégia, engenharia, operações, comercial e liderança.
  5. Revisar logs de colaboração. Zoom, Google Meet, Teams, e-mail corporativo e calendários podem revelar padrões.
  6. Limitar acesso por necessidade. Quanto menos contexto uma pessoa precisa carregar, menor o dano de uma conversa indevida.
  7. Monitorar OSINT. Perfis públicos, posts de contratação e apresentações podem revelar mais do que o necessário.

Isso se conecta diretamente com CTI aplicada à priorização: entender o adversário muda a forma de defender.

NDA sozinho não segura o risco

NDA é importante, mas não é controle suficiente.

Se a empresa depende apenas de contrato assinado, ela está reagindo depois que a informação já saiu. Segurança precisa chegar antes:

  • explicar exemplos concretos;
  • dar frases prontas para recusar abordagem;
  • orientar o que pode e não pode ser discutido;
  • criar trilha de reporte;
  • medir reincidência de abordagens.

O melhor controle é reduzir ambiguidade. Funcionário não deveria ter que decidir sozinho, em uma call paga, se uma informação é "só mercado" ou "estratégica".

O que isso muda para devs e times técnicos

Se você trabalha com tecnologia, dados, produto ou segurança, a mensagem é direta: sua visão interna tem valor.

Você pode não ter acesso ao board da empresa, mas talvez saiba:

  • qual sistema está sendo reescrito;
  • qual fornecedor foi escolhido;
  • qual pipeline falha com frequência;
  • quais métricas viraram prioridade;
  • qual região está em expansão;
  • qual integração está atrasada.

Para um concorrente, isso pode ser mais útil do que código-fonte.

Da próxima vez que chegar uma mensagem oferecendo dinheiro para "uma conversa rápida sobre o mercado", trate como evento de segurança. Não precisa entrar em pânico. Mas precisa pensar antes de aceitar.

Minha leitura

O caso iFood x Keeta é um lembrete de que segurança não vive só no SIEM, no WAF ou no scanner de vulnerabilidade.

Às vezes, o risco está em uma conversa aparentemente profissional. Às vezes, a prova está no metadado. Às vezes, o vazamento não é um arquivo roubado, mas uma sequência de respostas "inofensivas".

Segurança moderna precisa olhar para tecnologia, pessoas e contexto ao mesmo tempo.

Leia também

Referências