Cyber Security Brasilby Igor Deungaro

Logging de chamada de ferramenta: o evento de auditoria que importa

Logging de chamada de ferramenta: o evento de auditoria que importa

Quase toda plataforma de IA que vi em produção loga prompt e resposta. Quase nenhuma loga a chamada de ferramenta com os argumentos. E é a chamada de ferramenta que produz efeito no mundo — o prompt é só a intenção declarada.

Por que o log de prompt não serve para investigação

Num incidente, as perguntas são sempre as mesmas: o que foi acessado, por qual identidade, quando, e o que saiu daqui. Log de prompt não responde nenhuma. Pior: em injeção indireta, o prompt do usuário é inocente — a instrução hostil veio de um issue de repositório ou de uma página lida no meio do caminho.

O caso da Invariant Labs ilustra bem: uma issue maliciosa num repositório público bastou para redirecionar um agente com acesso ao GitHub a ler repositórios privados e publicar o conteúdo. O usuário não fez nada incomum — pediu para revisar issues abertas. Um log de prompt desse incidente não mostra absolutamente nada de errado.

Se o seu único registro é o que o usuário digitou, você não tem trilha de auditoria. Tem histórico de conversa.

O evento mínimo

Um evento útil de chamada de ferramenta tem sete campos:

  • Identidade do agente — individual, não a service account compartilhada da frota.
  • Identidade humana delegante, quando existir.
  • Servidor e nome da ferramenta.
  • Argumentos, com campos sensíveis mascarados mas com o destino sempre visível — URL, caminho, tabela.
  • Resultado: sucesso, negação, erro. Negação tem o mesmo valor que sucesso.
  • ID de correlação da tarefa, para reconstruir a sequência de ações.
  • Origem do conteúdo que entrou no contexto antes da chamada, se rastreável.

Esse último campo é o mais difícil e o mais valioso: é ele que conecta “leu esta página externa” com “chamou esta ferramenta de escrita trinta segundos depois”.

Onde o evento deve morar

No mesmo SIEM que recebe o resto. Não num painel do fornecedor de IA, não num arquivo local no host do agente. A razão é prática: correlação. O valor real aparece quando você cruza chamada de ferramenta com log de fluxo de rede, com evento de IAM e com log do proxy de saída.

O que dá para detectar com isso

  • Ferramenta chamada fora do horário ou frequência histórica daquele agente.
  • Sequência leitura externa → escrita externa dentro da mesma tarefa.
  • Argumento apontando para faixa privada ou link-local — tentativa de SSRF visível no log, não só no resultado.
  • Volume anômalo de chamadas, que costuma ser a primeira evidência de agente em loop descontrolado.

Nenhuma dessas detecções exige ferramenta nova. Exige o evento existir.

Este blog publica em português e inglês. / This blog publishes in Portuguese and English. EN · PT

Denunciar abuso

As inseguranças do sucesso da segurança cibernética

As inseguranças do sucesso da segurança cibernética. Tornar-se um grande profissional não precisa custar sua felicidade, mas a cultura da moagem torna isso provável. Nos últimos anos, a questão da saúde mental no setor de segurança cibernética ganhou destaque. Uma  pesquisa de 2019  revelou que 1 em cada 6 CISOs admitiu se  automedicar  para lidar com o estresse de seu trabalho. A tensão passa pelo escritório do CISO e permeia todo o setor. Um perfil que está crescendo  mais rápido que o orçamento  e uma sofisticação cada vez maior e  o impacto financeiro  dos ataques se combinam para transformar o que antes era um canto do departamento de TI em uma panela de pressão. John Hammond  , pesquisador de segurança cibernética da Huntress, falou sobre “ Hard Truths and Unexpected Realities: Lamentations in Producing Cybersecurity Content ” na  Intigriti 1337UP Live  , uma conferência online sobre bugs, em março de 2022. Seus...

DICA: comandos para pentest e segurança ofensiva

Fala galera, blz ? Segue uma lista de comandos maravilhosa, voltada para teste de vulnerabilidades. Observação Pertinente: Os TIPOS de COMANDOS e as INSTRUÇÕES estão em INGLÊS! NÂO ME RESPONSABILIZO POR USO INDEVIDO. Pré-requisitos: ✔️  Python 3.5 ✔️  OS que suporte Python (eu utilizei Kali) Reconnaissance / Enumeration Extracting Live IPs from Nmap Scan nmap 10.1.1.1 --open -oG scan-results; cat scan-results | grep "/open" | cut -d " " -f 2 > exposed-services-ips Simple Port Knocking for x in 7000 8000 9000; do nmap -Pn –host_timeout 201 –max-retries 0 -p $x 1.1.1.1; done DNS lookups, Zone Transfers & Brute-Force whois domain.com dig {a|txt|ns|mx} domain.com dig {a|txt|ns|mx} domain.com @ns1.domain.com host -t {a|txt|ns|mx} megacorpone.com host -a megacorpone.com host -l megacorpone.com ns1.megacorpone.com dnsrecon -d megacorpone.com -t axfr @ns2.megacorpone.com dnsenum domain.com nslookup -> set type=any -> ls -d domain.com for ...

Atacantes precisam de menos de 10 horas para encontrar fraquezas

Atacantes precisam de menos de 10 horas para encontrar fraquezas. Configurações vulneráveis, falhas de software e serviços da Web expostos permitem que hackers encontrem pontos fracos exploráveis ​​nos perímetros das empresas em apenas algumas horas, não em dias. O hacker ético médio pode encontrar uma vulnerabilidade que permite a violação do perímetro da rede e, em seguida, explorar o ambiente em menos de 10 horas, com testadores de penetração focados na segurança da nuvem obtendo acesso mais rapidamente aos ativos direcionados. Além disso, uma vez que uma vulnerabilidade ou fraqueza é encontrada, cerca de 58% dos hackers éticos podem invadir um ambiente em menos de cinco horas. Isso está de acordo com uma pesquisa com 300 especialistas do SANS Institute e patrocinada pela empresa de serviços de segurança cibernética Bishop Fox, que também descobriu que as fraquezas mais comuns exploradas pelos hackers incluem configurações vulneráveis, falhas de software e serviços da Web expost...

Quem sou eu

Minha foto
Igor Deungaro
Bem Vindo ao Cyber Security Brasil, espero que goste !!!
Ver meu perfil completo

Cyber Security

Rate Limiting and Circuit Breakers for Agents in a Loop

A compromised human acts in minutes and hesitates at a strange instruction. An agent acts in milliseconds, in a loop, and does not hesitate. That speed difference changes which control matters: prevention still counts, but containment counts more. Two failure modes, one mitigation The first mode is malicious: a poisoned context tells the agent to iterate over records and send everything outward. The second is mundane: an orchestration bug puts the agent in a cycle calling the same tool thousands of times. The second is far more common and produces the same early symptoms — which is good news, because the control against error also works against attack. Limits worth having Call budget per task. A task that needed 12 calls and has made 400 is wrong, whatever the reason. Cut it and ask for human intervention. Per-tool limits, not global ones. Fifty reads may be normal; fifty external writes almost never are. Data-volume limits, not just counts. A single call returning 2 GB is...

Marcadores