FlawOpen

flawopen.com/AI Security/ghostjacking-ai-agent-poisoned-observability-logs-august-2026

● Mapeamento da FlawOpen: CWE-1427 · Severidade editorial: Média
Pesquisa · FlawOpen

GhostJacking: logs e agentes de IA

Pesquisa mostra como telemetria manipulada pode influenciar um agente integrado. Sem CVE ou vítima confirmada.[1], [2]

💡 Explicação em Linguagem Simples (ELI5)

Imagine uma recepcionista bloqueando uma entrega suspeita, mas copiando o bilhete do remetente no registro do incidente. Mais tarde, uma pessoa despachante confirma um número real de chamado e uma lacuna verdadeira na política de DNS da configuração de teste; então confia no endereço escolhido pelo atacante que aparece no mesmo bilhete e altera a agenda pública que informa aos navegadores e ao e-mail onde ficam os serviços da empresa. O registro era evidência, não autorização para fazer a mudança; uma verificação de política e uma aprovação separadas devem controlá-la.[1]

Conceitos Centrais e Termos

GhostJacking
Nome usado pela Tenet Security para demonstrações em que conteúdo controlado por um atacante em eventos de observabilidade influencia um agente de IA conectado a essas ferramentas. É um rótulo de pesquisa, não um CVE.[1], [2]
Indirect prompt injection
Instruções inseridas em dados que o modelo deve analisar, em vez de fornecidas diretamente pelo usuário.[1], [2], [4]
Evento de observabilidade
Um log, alerta, rastreamento ou registro de erro que descreve atividade do sistema. Alguns campos podem conter texto fornecido por uma solicitação externa.[1], [2]
Autorização independente
Verificação de política feita fora do modelo que avalia ator, alvo, alteração solicitada e aprovação antes de uma ferramenta executar uma ação importante.[2], [5]
CWE-1427
Classe de fraqueza do MITRE para neutralização inadequada de entradas usadas em prompts de LLM. Esta é uma associação conceitual da FlawOpen; Tenet, ngCERT e nenhum registro CVE a atribuíram ao GhostJacking.[4], [1], [2]
Severidade editorial
A ngCERT classifica o risco e o dano do alerta como altos. A FlawOpen classifica este resumo como Médio porque as demonstrações exigem um agente com integrações e permissões de alteração relevantes; não há vítima com violação confirmada. Esta é uma avaliação editorial, não uma pontuação do fornecedor.[2], [1]

Mapeamentos de frameworks

Fluxo de Ataque Passo a Paso

Passo 1

O agente recebe permissão para investigar

A pesquisa da Tenet descreve agentes de programação ou operações conectados a ferramentas como Cloudflare, Datadog e Sentry. A precondição relevante é o agente poder ler conteúdo externo de eventos e executar ações consequentes com as permissões existentes.[1]

Passo 2

Uma solicitação vira evidência registrada

Na demonstração da Tenet com Cloudflare, uma solicitação é bloqueada por um WAF, mas um campo controlado pelo atacante permanece no registro do evento. Uma solicitação bloqueada ainda pode deixar texto não confiável para um agente ler depois.[1], [2]

Passo 3

Telemetria plausível contorna defesas contra instruções explícitas

A Tenet relata que comandos explícitos foram rejeitados em seus testes. Na demonstração bem-sucedida com Cloudflare, usou telemetria estruturada, semelhante à de um scanner, com referência de chamado, citação de conformidade e métrica; o agente verificou algumas afirmações e depois confiou em valores DNS não verificados controlados pelo atacante. Esta é uma demonstração de injeção indireta de prompt relatada pelos pesquisadores, não uma evidência de violação real de uma vítima.[1], [2]

Passo 4

As permissões existentes transformam influência em impacto

A Tenet relata que sua demonstração controlada levou um agente a alterar DNS por meio de uma ferramenta Cloudflare integrada. O resultado depende das permissões e da configuração do agente; não prova que a Cloudflare foi comprometida nem que sistemas de clientes foram atacados.[1]

Passo 5

Uma política separada pode bloquear a alteração

A aplicação deve tratar a proposta do modelo como não confiável. Um serviço de autorização no servidor precisa verificar o recurso e a alteração exatos, exigir aprovação humana autorizada quando apropriado e registrar a decisão antes de chamar a API do provedor.[2], [5]

Código-Fonte: Vulnerável vs. Seguro

São trechos ilustrativos da aplicação, não o código vulnerável ou corrigido de nenhum produto citado. O formato inseguro dá acesso direto a uma ferramenta de alteração ao agente que lê texto não confiável de eventos. O formato protegido separa proposta e execução: um serviço independente consome uma aprovação de uso único, vinculada ao ator e à alteração exata, e então aplica a política antes de chamar o provedor. A identidade do ator vem do contexto autenticado do servidor, não de um campo controlado pelo chamador; o modelo não pode escolhê-la. Uma instrução no prompt, sozinha, não é controle de autorização. O código de produção também deve validar esquemas, titularidade do tenant e do recurso, expiração da aprovação, proteção contra repetição, persistência de auditoria e erros do provedor.[1], [2], [5]

IMPLEMENTAÇÃO VULNERÁVEL
// Integração insegura ilustrativa; não é código-fonte da Cloudflare, Datadog, Sentry ou Tenet.
async function investigate(event: EventRecord) {
  return agent.run({
    context: event.message,
    tools: [cloudflare.updateDnsRecord]
  });
}
PATCH SEGURO E ROBUSTO
// Limite de controle ilustrativo; o modelo pode propor, mas não autorizar nem aplicar.
type DnsProposal = { zoneId: string; name: string; value: string };

async function proposeDnsChange(event: EventRecord): Promise<DnsProposal> {
  return agent.propose({ evidence: markUntrusted(event.message) });
}

async function applyDnsChange(
  proposal: DnsProposal,
  approvalId: string
) {
  const actorId = auth.requireAuthenticatedActorId();
  const validatedProposal = DnsProposalSchema.parse(proposal);
  const approval = await approvals.consumeOnce(approvalId, { actorId });
  if (!approval || approval.actorId !== actorId ||
      approval.zoneId !== validatedProposal.zoneId ||
      approval.name !== validatedProposal.name ||
      approval.value !== validatedProposal.value ||
      !policy.canChangeDns(actorId, validatedProposal.zoneId, validatedProposal.name)) {
    throw new Error('DNS change is not independently authorized');
  }
  // Falhe fechado se não for possível registrar a decisão de autorização antes da mutação.
  await audit.record({ actorId, approvalId, action: 'dns-change', decision: 'authorized' });
  try {
    await cloudflare.updateDnsRecord(validatedProposal);
  } catch (error) {
    await audit.record({ actorId, approvalId, action: 'dns-change', outcome: 'provider-failed' });
    throw error;
  }
  await audit.record({ actorId, approvalId, action: 'dns-change', outcome: 'succeeded' });
}

Lista de Verificação de Segurança para Engenharia

Fontes

← AI Security Directory →