Agentic Testari Sentinel Hub · FriendlyAI agentictestari.com
Confidencial
L3 MAX Public-max · não destrutivo

Avaliação de superfície pública — {{CLIENT_NAME}}

WordPress + Cloudflare (Agência MCN). Riscos graves em n8n público e enumeração de utilizadores WP, além de headers fracos.

Alvo {{CLIENT_DOMAIN}} Data 2026-07-31 RoE public-max · não destrutivo Engagement eng_allfluence_l3_1302
2 Alto
2 Médio
3 Info
1 Ok / controlado

Resumo executivo

Porque agir agora

Estes achados não são teóricos: são links públicos que um humano ou um agente hacker pode consumir hoje. Cada cartão abaixo diz o que podem fazer com a informação — para a liderança e o time técnico levarem o risco a sério e fecharem o fix.

Corrida L3 max em https://{{CLIENT_DOMAIN}}/ (e zona de marca). Os dois riscos ALTO pedem ação imediata de ops e WordPress. O registo do teste inclui trilha ParviClaw Core + AWP (verificável offline pelo cliente).

Stack nesta corrida

ComponenteIncluído?Nota
Sentinel L3 public-maxSIMDNS, headers, paths, WP enum, brand-zone, walk
ParviClaw CoreSIMleaves hash-ligadas · engagement eng_allfluence_l3_1302
AWPSIM (lab)recibo local_awp_dev · verify offline com npx
ParviSightPARCIALwalk multi-página (Chromium full bloqueado no host de lab)
PayBotFin Witness liveNÃOsem API key neste run — não claim metering

Achados

Cada achado inclui: problema, onde (com link), de quem é, o que um atacante ou agente pode fazer, PoC (prova — não corrige), como resolver e como validar o fix.

AF-H-N8N

n8n de automação exposto na internet pública

ALTO
O problema

A instância n8n responde na internet. /rest/settings revela Docker, SQLite e endpoints de formulário; /healthz devolve ok sem autenticação. Superfície de automação crítica não deve ser pública.

Onde

https://n8n.{{CLIENT_DOMAIN}}/ · /signin · /rest/settings · /healthz

O que um atacante ou agente hacker pode fazer
  • Humano: mapear a automação da marca, procurar webhooks/API sem auth, abusar workflows se expostos, pivotar para credenciais de Ads/CRM/e-mail guardadas no n8n.
  • Agente (LLM+tools): em loop 24/7 — inventariar endpoints, testar auth, encadear com WP/login; se obtiver execução ou secret, exporta tokens e replica o ataque noutros alvos.
  • Se invasor/destrutivo (após acesso real): sequestrar campanhas, apagar/alterar automações, roubar bases ligadas ao n8n, usar o host como pivot. O nosso L3 só prova a exposição (leitura) — não executa isto.
De quem é

{{CLIENT_NAME}} — operação / infra de automação (n8n Docker). Não é o site de marketing WordPress sozinho; é o vosso produto de workflows no DNS da marca.

PoC (prova — não corrige)

Comandos de leitura para o time reproduzir o achado. Não alteram o sistema.

curl -sS https://n8n.{{CLIENT_DOMAIN}}/healthz\ncurl -sS https://n8n.{{CLIENT_DOMAIN}}/rest/settings | head -c 400
Como resolver

Retirar n8n da internet pública: VPN, Cloudflare Access, IP allowlist ou rede privada. Auth forte. Restringir /rest/* e health se não precisarem de ser públicos. Desativar setup se já provisionado.

Como validar o fix

Os mesmos curls a partir da internet devem falhar (401/403/timeout).

AF-H-WP-USERS

Enumeração de utilizadores WordPress via REST API

ALTO
O problema

A API REST lista autores (id, nome, slug, avatars) sem login — facilita phishing e ataques de força bruta a contas reais.

Onde

https://{{CLIENT_DOMAIN}}/wp-json/wp/v2/users → HTTP 200 (ex.: utilizador público com slug visível)

O que um atacante ou agente hacker pode fazer
  • Humano: obtém lista de logins (slug + nome) sem senha — atalho para força bruta, password spray e phishing com nome real.
  • Agente: lê o JSON sozinho, gera wordlists com os slugs, cruza leaks e monta phishing em escala; junta com wp-login e outros buracos no mesmo run.
  • Cadeia invasora/destrutiva: recon → credencial fraca/reutilizada → admin WP → deface, malware SEO, dump de leads, backdoor. O JSON sozinho não apaga o site; alimenta a invasão.
De quem é

{{CLIENT_NAME}} — WordPress (configuração da REST API / permissões).

PoC (prova — não corrige)

Comandos de leitura para o time reproduzir o achado. Não alteram o sistema.

curl -sS https://{{CLIENT_DOMAIN}}/wp-json/wp/v2/users
Como resolver

Desativar listagem pública de users (plugin de segurança, filtro REST, ou regra no servidor/WAF). Limitar /wp-json/ ao necessário.

Como validar o fix

Endpoint devolve 401/403 ou lista vazia sem autenticação.

AF-M-HEADERS

Headers de segurança em falta na resposta principal

MÉDIO
O problema

Ausência de HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Permissions-Policy na resposta HTML principal (atrás de Cloudflare).

Onde

https://{{CLIENT_DOMAIN}}/ (headers da resposta)

O que um atacante ou agente hacker pode fazer
  • Humano/agente: facilita clickjacking, MIME sniffing, XSS de impacto maior se houver injeção, e downgrade de transporte sem HSTS.
  • Na prática: raramente “invade sozinho”; multiplica o dano de outros bugs e de phishing (site mais fácil de embutir/imitar em iframe).
De quem é

{{CLIENT_NAME}} — site / Cloudflare / hosting.

PoC (prova — não corrige)

Comandos de leitura para o time reproduzir o achado. Não alteram o sistema.

curl -sSI https://{{CLIENT_DOMAIN}}/ | grep -iE 'strict|content-security|x-frame|x-content|referrer|permissions'
Como resolver

Configurar headers no Cloudflare (Transform Rules) ou no servidor/WordPress. Preferir HSTS com includeSubDomains quando estável.

Como validar o fix

O grep acima mostra os headers presentes e corretos.

AF-M-WP-LOGIN

wp-login.php acessível publicamente

MÉDIO
O problema

Página de login WordPress exposta — superfície clássica de força bruta e scanning.

O que um atacante ou agente hacker pode fazer
  • Humano: porta de autenticação na internet — brute force, spray, stuffing de credenciais vazadas.
  • Agente: combina users do REST + wordlists + rate-limit fraco em loop contínuo; tenta N sites com o mesmo playbook.
  • Com sucesso de login: vira invasão (admin) e, se quiser, destrutivo (conteúdo, backup, persistência).
De quem é

{{CLIENT_NAME}} — WordPress.

PoC (prova — não corrige)

Comandos de leitura para o time reproduzir o achado. Não alteram o sistema.

curl -sS -o /dev/null -w '%{http_code}\n' https://{{CLIENT_DOMAIN}}/wp-login.php
Como resolver

Rate-limit, 2FA, mudar URL de login, ou restringir por IP/CF Access para equipa interna.

Como validar o fix

Login não é trivialmente acessível a partir da internet aberta (403/challenge/URL alterada).

Anexos de evidência (AWP + Core)

Cada ficheiro tem propósito diferente. Links sozinhos não bastam — leia a legenda.

1) awp-receipt.json — cripto AWP

O que é: recibo do Agent Witness Protocol (assinado, offline-verificável).

O que prova: integridade do registo do nosso teste/engagement.

O que NÃO é: não prova sozinho o bug no vosso host (isso é o PoC curl acima).

→ Descarregar awp-receipt.json

2) leaves.jsonl — livro ParviClaw Core

O que é: diário append-only com leaves hash-ligadas (schema core.control.leaf.v1).

O que prova: timeline do engagement (sessões, navegações, confirmações de findings).

O que NÃO é: não se verifica com awp verify (formato diferente).

→ Descarregar leaves.jsonl · leaf-chain.txt (PASS)

3) retest-raw.json — bruto L3

O que é: dumps HTTP (status, headers, previews) dos probes.

Para quê: o vosso time reproduzir/inspecionar respostas.

Não é cripto AWP/PayBot.

→ Descarregar retest-raw.json

4) agentic-walk.json — mapa agentico

O que é: mapa multi-página (URLs, forms, superfícies de login).

Não é o recibo AWP — é inventário de superfície.

→ Descarregar agentic-walk.json

Como verificar o recibo AWP (open-source)

Verificação independente pelo cliente ou auditor

O AWP é código aberto (agent-witness-protocol no npm). Qualquer pessoa com Node.js pode validar o recibo offline, sem confiar só no PDF e sem precisar de chamar o nosso servidor.

Passos:

// 1) Guarde o ficheiro awp-receipt.json do relatório
// 2) No terminal (Node.js 18+):
npx agent-witness-protocol verify awp-receipt.json

// Deve aparecer: RESULT: PASS
// (signature Ed25519, schema WitnessRecord, inclusion Merkle, etc.)

O receipt já inclui public_key_pem / public_key_raw_base64 — o verify usa isso se não passar --pubkey.

O que o PASS significa (honesto):
• o recibo é consistente, assinado e não foi adulterado desde que foi “witnessed”;
NÃO prova sozinho o problema no vosso site (Grafana, n8n, WP…) — isso é o PoC curl de cada achado;
• o que o PASS prova é a integridade do nosso registo de teste (trilha Sentinel / Core / AWP);
• serve a qualquer auditor como prova forte da veracidade e não-adulteração do registo do engagement, não como “o bug existe só porque o AWP passou”.
• modo lab usa chaves DEV_LAB no receipt — não é cerimónia multi-party / bank.

Para o diário Core (leaves.jsonl): abra o ficheiro linha a linha e confira leaf-chain.txt (PASS). Formato distinto do AWP.

Ordem de correção para o time

  1. Hoje — n8n — Retirar n8n da internet pública ou pôr Access/VPN (AF-H-N8N).
  2. Hoje — WP users — Bloquear /wp-json/wp/v2/users público (AF-H-WP-USERS).
  3. Esta semana — headers + login — HSTS/CSP/XFO + hardening wp-login (AF-M-*).
  4. Hygiene — security.txt, alinhar www (hoje 404), limpar mail.* default.