6 apps deliberadamente vulnerables, un loop autónomo — hasta que el nombre deja de aplicar.

Las apps “deliberadamente vulnerables” — DVWA, Juice Shop, WebGoat, VAmPI y compañía — existen para que encuentres bugs. Y encontrarlos es trivial: están puestos ahí. El verdadero desafío, el que importa en producción, es otro: correr el programa de seguridad entero hasta que el nombre deje de tener sentido. Hasta sacarle, literalmente, lo “Damn Vulnerable” a la Damn Vulnerable Web Application y dejarla en solo… una Application.

Eso es lo que hicimos con FaradAI. No “encontramos cosas en DVWA”. La arreglamos — y a otras cinco — hasta confirmar, con un re-scan, que lo que era explotable ya no lo era.

El concepto

Un lab vulnerable es el lugar honesto para probar un programa, no un scanner. Cualquiera marca los hallazgos. La pregunta real es si podés cerrar el círculo completo:

encontrar → probar que es explotable → priorizar → arreglar → re-testear y confirmar que quedó cerrado.

Si podés hacer eso de punta a punta, “Damn Vulnerable” deja de aplicar. Si no, tenés una pila de hallazgos y el nombre sigue intacto.

Las 6 apps (y por qué estas)

Metimos los cuatro clásicos y le sumamos la capa que nadie está testeando todavía:

• DVWA (PHP), Juice Shop (Node/SPA+API), WebGoat (Java/Spring), VAmPI (API Python) — el espectro web/API clásico.
• PromptMe (LLM / OWASP LLM Top 10) y Damn Vulnerable MCP (servidor MCP sobre SSE) — la superficie de IA, donde las vulnerabilidades son prompt injection, tool poisoning y system-prompt leakage en vez de SQLi y XSS.

El mismo loop para los seis, todo en un solo workspace de Faraday.

El loop

Scan estático (SAST + SCA + secrets) → Faraday
   ↓
Pentest autónomo con FaradAI (Claude + Codex) → exploits validados y encadenados
   ↓
Triage: dedup + priorización de todo junto
   ↓
Patch (FaradAI o a mano)
   ↓
Re-scan → Faraday reconcilia: arreglado → closed, abierto → open

Los scanners aportan amplitud (ruidosa, sin probar). FaradAI convierte el “quizás” en “acá está el exploit funcionando”. El triage ordena el firehose. El re-scan dice la verdad: qué se cerró.

Lo que pasó en una corrida real

La salida en crudo fue 620 hallazgos entre las seis apps. La mayoría, ruido estático informativo. Y después FaradAI probó qué era real:

• 48 exploits validados con evidencia de request/response — no ecos de scanner.
• En DVWA: command injection → RCE como www-data, file upload → web shell, SQLi dumpeando el hash del admin.
• En Juice Shop: bypass de login por SQLi, JWT alg:none, IDOR en baskets y órdenes.
• En Damn Vulnerable MCP: una tool con whitelist bypasseable → RCE no autenticado como root, y credenciales filtradas desde la descripción de otra tool.
• En PromptMe: prompt injection que filtró el system prompt… con una API key hardcodeada adentro.

Cosas que ningún SAST/SCA ve. Después, un pase de triage sobre los 77 críticos/altos → 65 confirmados y un plan de patch de 71 fixes (bumps de dependencias, queries parametrizadas, shell=False en la tool MCP, sacar la API key del system prompt).

El arco en una sola corrida: 620 en crudo → 48 exploits probados → 77 priorizados → 71 fixes accionables. Y recién ahí, con los fixes aplicados y el re-scan confirmando el cierre, el “Damn Vulnerable” empieza a caerse del nombre.

Por qué importa fuera del lab

Lo lindo del lab es que es seguro equivocarse. Pero el loop no cambia cuando el target es tu producción: encontrar nunca fue el cuello de botella — probar, priorizar y cerrar sí. Si podés sacarle lo “Damn Vulnerable” a seis apps distintas (web, API, LLM, MCP) en una corrida, ese mismo loop es el que querés corriendo contra lo que shippeás todas las semanas.

No es “encontramos 300 cosas”. Es “probamos que estas eran explotables, las arreglamos y confirmamos que ya no están”. Esa es la diferencia entre una pila de hallazgos y un programa de seguridad — y entre una Damn Vulnerable Web Application y, simplemente, una app.

Sacale lo “Damn Vulnerable” a lo tuyo — de scan a fix confirmado, en un solo lugar: Faraday · FaradAI →

From “Damn Vulnerable” to Just an App was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you do offensive security in 2026, you’ve almost certainly pointed Claude Code or Codex at a target and watched it find real bugs. The agents are genuinely good at it: recon, reading source, chaining an SSRF into a credential leak, writing the PoC.

Then the terminal scrolls, the session ends, and… that’s it. The findings live in your scrollback. There’s no dedup against last week’s run, no history, no report you can hand a client, no correlation with the Burp and nuclei output sitting in another folder.

The model is a brilliant operator with no memory and no filing system. This post is about giving it one.

1. An LLM agent is not a security program

Running Claude or Codex ad-hoc gets you findings. It does not get you:

• Deduplication — the same IDOR reported on three branches, three times.
• History — was this vuln here last month? Did the last fix actually hold?
• Prioritization — 40 findings in a transcript, no ranking by real exploitability.
• Reporting — a client wants a PDF, not a copy-pasted chat log.
• Correlation — your SAST, DAST, and scanner results live in unrelated silos.

The intelligence is there. The system of record is missing. That’s the exact split FaradAI is built around: the LLM is the operator; Faraday is the memory, the triage engine, and the report.

2. Claude and Codex, orchestrated — not babysat

FaradAI runs the same agents you already use, as a managed pentest instead of a one-off chat. It’s the FaradAI Security Scanner — an agent inside your Faraday instance — and you trigger it with faraday-cli, passing the executor a single JSON of parameters:

faraday-cli agent run \
  -a "$FARADAI_AGENT_ID" \
  -e aipentest \
  -w engagement \
  -p '{
    "TARGET": "<in-scope host / app>",
    "INSTRUCTION": "Comprehensive web assessment",
    "MODE": "dual",
    "ROUNDS": "5"
  }'

MODE picks who does the work: claude, codex, or dual. Dual mode is the interesting one — Claude and Codex take turns on the same target across ROUNDS, each critiquing and building on the other's work. Two models with different strengths, adversarially checking each other, is a materially better tester than either alone — and you never had to sit in the loop copy-pasting between two chat windows.

3. Everything lands in Faraday — including the other silos

However the findings are produced, they’re pushed to Faraday automatically at the end of the run, deduplicated and grouped under one command in the workspace. That’s where the LLM output stops being scrollback and becomes a managed vulnerability:

• Ranked by validated exploitability, not raw severity.
• Tracked over time — reopened if it comes back, closed when a retest confirms the fix.
• Exportable as a client-ready report.

And critically, your other tools stop being silos. Import their output into the same workspace so the LLM’s validated exploits sit next to everything else:

# token auth: seed the config file (faraday-cli auth has no --token flag)
printf 'auth:\n  faraday_url: %s\n  token: %s\n' "$FARADAY_URL" "$FARADAY_TOKEN" > ~/.faraday-cli.yml
faraday-cli tool report nuclei.json    -w engagement
faraday-cli tool report burp.xml       -w engagement
faraday-cli tool report nessus.nessus  -w engagement
faraday-cli tool report semgrep.sarif  -w engagement

Faraday speaks the formats your existing stack already emits. Nuclei, Burp, Nessus, semgrep, and a FaradAI run all converge into one deduplicated, prioritized, reportable picture.

4. One practical note: provider trusted access

Offensive work trips content filters. Frontier providers can refuse, throttle, or block requests that look like exploit development or scanning against real hosts. Before running Claude or Codex against live client targets, enroll in the provider’s trusted-access program:

• OpenAI (Codex / o* / gpt-*): Enterprise Trusted Access for Cyber.
• Anthropic (Claude): document your authorized-testing context at the org level; the agent runs offensive work as long as the request carries clear authorization — which FaradAI’s prompts already provide.

Don’t obfuscate intent to dodge filters. It’s unreliable and it wrecks the audit trail a real engagement depends on. Authorize properly and the agents run clean.

5. The takeaway

You already trust Claude and Codex to find vulnerabilities. The missing piece was never the intelligence — it was the program around it: memory, dedup, prioritization, reporting, and one place where every tool’s output converges.

Keep using the agents you like. Point them at Faraday, and turn a brilliant one-off into a security program.

Give your AI pentester a system of record — Faraday →

Using Claude or Codex for Pentesting? Give It a System of Record. was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

You don’t need a special product to do AI penetration testing. If you have the Claude Code CLI or the Codex CLI, you already have an autonomous operator that can enumerate a target, find a vulnerability, write a working exploit, and escalate to root. The models are genuinely good at it.

The problem is what happens next: the findings live in your terminal scrollback. No dedup, no history, no report, and — crucially — no way to see them next to the SAST, SCA, and DevSecOps findings your team already collects.

This post closes that loop end to end: run a real pentest from the console, get the findings into Faraday, and put AI-validated exploits side by side with every other source of vulnerabilities.

1. Run the pentest from the console

Both CLIs run in a shell with tools, so give them an attack box (a Kali container or VM with your usual tooling) and an authorized target. The only thing that changes between them is the launch command — the prompt is the same.

Claude Code:

claude "$(cat pentest-prompt.txt)"

Codex:

codex "$(cat pentest-prompt.txt)"

And pentest-prompt.txt — a good kickoff prompt does three things: establishes authorization, sets a concrete goal, and pins the finding format you'll need later.

You are performing an authorized penetration test of the HackTheBox machine at 10.129.1.52 — I own this instance and standard HackTheBox rules apply. Work autonomously using your shell tools. Goal: capture the user and root flags. Enumerate all services, identify vulnerabilities, and develop and run working exploits — don't stop at "possible," prove it. Escalate privileges to root. Keep a running findings list. For every confirmed vulnerability record: host, port, service, name, severity (critical|high|medium|low|informational), description, evidence, cve, references, remediation. A finding only counts once you've demonstrated it.

That’s it — the agent takes over from there: recon, exploitation, privilege escalation, iterating on its own failures.

One operational note: frontier providers can throttle or refuse requests that look like offensive security. For real engagements, enroll your org in the provider’s trusted-access program (OpenAI’s Enterprise Trusted Access for Cyber; Anthropic’s usage-policy process) and keep your authorization documented. Don’t obfuscate intent to dodge filters — it’s unreliable and wrecks your audit trail.

2. What a run actually produces

Here’s a real chain from a run against HackTheBox’s Cache box — the kind of output you get back, condensed:

• Recon → http://10.129.1.52/jquery/functionality.js leaks hardcoded creds ash:H@v3_fun; vhost enumeration surfaces the OpenEMR-based HMS app on hms.htb.
• Auth bypass + SQLi (CVE-2018–15152, CVE-2019–3964) → the OpenEMR patient-portal registration flow bypasses authentication; a SQL injection in add_edit_event_user.php (eid param) dumps the users_secure table — the admin hash, cracked offline.
• RCE (CVE-2019–8377) → an authenticated PHP file-write via manage_site_files.php drops a webshell, giving command execution on the host.
• Cleartext creds in memcached (:11211) → get user / get passwd return luffy:0n3_p1ec3; SSH in as luffy → user flag.
• Privesc (docker group) → luffy sits in the docker group, so docker run -v /:/mnt --rm ubuntu cat /mnt/root/root.txt reads the flag as root → root flag.

Multi-step, chained, and every link demonstrated rather than guessed. That’s the value an AI pentester adds over a scanner — but right now it’s trapped in a transcript. Let’s fix that.

3. Send the findings to Faraday

Point at your Faraday first (self-hosted Community or hosted Personal — how to get each is at the end):

export FARADAY_URL="https://scan.apps.faradaysec.com"   # or http://localhost:5985
export FARADAY_TOKEN="<your-api-token>"

Now bridge the findings across. Pick whichever fits your workflow.

Bridge A — push straight to the Faraday API

Faraday ingests findings in one call. Hand the agent the endpoint, token, and payload shape and let it POST — a follow-up prompt in the same session:

Push every confirmed finding to Faraday. POST to $FARADAY_URL/_api/v3/ws/htb-cache/bulk_create with headers Authorization: Token $FARADAY_TOKEN and Content-Type: application/json. Group vulnerabilities by host IP. Body shape: {"hosts":[{"ip":"<ip>","hostnames":["<host>"],"vulnerabilities":[{"name":"...","desc":"...","severity":"high","type":"Vulnerability"}]}]} severity ∈ critical|high|medium|low|informational.

The same call by hand, for reference:

curl -sS -X POST "$FARADAY_URL/_api/v3/ws/htb-cache/bulk_create" \
  -H "Authorization: Token $FARADAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "hosts": [{
      "ip": "10.129.1.52",
      "vulnerabilities": [{
        "name": "OpenEMR Authenticated RCE (CVE-2019-8377)",
        "desc": "Auth bypass (CVE-2018-15152) + SQLi (CVE-2019-3964) recover admin creds; authenticated file-write yields RCE; chained to root via cleartext memcached creds and the docker group.",
        "severity": "critical",
        "type": "Vulnerability"
      }]
    }]
  }'

Bridge B — emit a reviewable CSV first

Prefer a human gate before anything hits Faraday? Have the agent write a CSV, eyeball it, then import:

Output all confirmed findings as CSV with exactly these columns: host,name,severity,description,cve,references. One row per vulnerability, severity ∈ critical|high|medium|low|informational, quote any field containing a comma. Output only the CSV.

pip install faraday-cli
# token auth: seed the config file (faraday-cli auth has no --token flag)
printf 'auth:\n  faraday_url: %s\n  token: %s\n' "$FARADAY_URL" "$FARADAY_TOKEN" > ~/.faraday-cli.yml
faraday-cli tool report findings.csv -w htb-cache

Bridge C — connect via the Faraday MCP

If you’ve wired a Faraday MCP server into your agent, skip files and HTTP entirely — the same session that finds the bug files it:

Using the connected Faraday MCP server, create each confirmed finding as a vulnerability in workspace htb-cache, setting name, severity, description, and evidence.

(Confirm the Faraday MCP server is available in your setup before relying on this bridge.)

4. See it in Faraday

Open the htb-cache workspace. The findings are now deduplicated, ranked by severity, and — this is the part that matters — permanent. Re-run the box next month and Faraday reconciles against what's already there instead of creating duplicates, so you can actually tell whether a fix held.

5. The real payoff: AI pentest next to every other vuln source

A confirmed exploit chain is powerful, but it’s one lens. Your static scanners see code you never reached at runtime; your SCA sees vulnerable dependencies; your DevSecOps pipeline sees IaC and secrets. Each is noisy and broad; the AI pentest is precise and deep. Their value compounds only when they land in the same place.

faraday-cli speaks the formats your existing stack already emits — import them into the same workspace:

faraday-cli tool report semgrep.sarif  -w htb-cache   # SAST
faraday-cli tool report trivy.json     -w htb-cache   # SCA / containers
faraday-cli tool report nuclei.json    -w htb-cache   # DAST
faraday-cli tool report burp.xml       -w htb-cache

Now one workspace answers the question no single tool can: of everything we know is wrong, what did an attacker actually prove they could exploit? The SAST flags a hundred sinks; the AI pentest shows which one became RCE. The SCA lists forty vulnerable packages; the pentest shows which one was reachable and chained to root. That correlation — breadth from scanners, proof from the AI pentester, all deduplicated and prioritized — is the difference between a pile of findings and a security program.

6. Where the findings go: Community or Personal

Both destinations take the exact same commands above — pick where you want the data to live.

Faraday Community — free, self-hosted, open-source. Run it on your own box (default http://localhost:5985) and take an API token from your user settings:

export FARADAY_URL="http://localhost:5985"
export FARADAY_TOKEN="<your-community-api-token>"

Faraday Personal — hosted, nothing to run. Create your tenant at scan.faradaysec.com; your instance lives at scan.apps.faradaysec.com:

export FARADAY_URL="https://scan.apps.faradaysec.com"
export FARADAY_TOKEN="<your-personal-api-token>"

Run the pentest with the console you already use, bridge the findings in, and triage them alongside everything else you know. The operator is the AI; the system of record is Faraday.

Try FaradAI

Everything here — the autonomous pentest, the exploitability validation, the triage — is FaradAI, running inside Faraday. Instead of wiring the flow by hand, let an autonomous offensive agent pentest every target and hand you the prioritized findings in one place.

👉 Meet FaradAI: faradaysec.com/faradai

Give your AI pentester a home for its findings — Faraday Community · Faraday Personal →

Hands-On: Claude/Codex Pentest → Faraday was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

No necesitás un producto especial para hacer pentesting con IA. Si tenés la CLI de Claude Code o la de Codex, ya tenés un operador autónomo que puede enumerar un target, encontrar una vulnerabilidad, escribir un exploit que funciona y escalar a root. Los modelos son genuinamente buenos en esto.

El problema es lo que pasa después: los hallazgos quedan en el scrollback de tu terminal. Sin dedup, sin historial, sin reporte y — lo más importante — sin manera de verlos al lado de los hallazgos de SAST, SCA y DevSecOps que tu equipo ya junta.

Este post cierra ese loop de punta a punta: corrés un pentest real desde la consola, metés los hallazgos en Faraday, y ponés los exploits validados por IA al lado de todas las demás fuentes de vulnerabilidades.

1. Corré el pentest desde la consola

Las dos CLIs corren en una shell con herramientas, así que dales una attack box (un contenedor o VM de Kali con tu toolkit de siempre) y un target autorizado. Lo único que cambia entre una y otra es el comando de arranque — el prompt es el mismo.

Claude Code:

claude "$(cat pentest-prompt.txt)"

Codex:

codex "$(cat pentest-prompt.txt)"

Y pentest-prompt.txt — un buen prompt de arranque hace tres cosas: deja sentada la autorización, fija un objetivo concreto y clava el formato de hallazgo que vas a necesitar después.

You are performing an authorized penetration test of the HackTheBox machine at 10.129.1.52 — I own this instance and standard HackTheBox rules apply. Work autonomously using your shell tools. Goal: capture the user and root flags. Enumerate all services, identify vulnerabilities, and develop and run working exploits — don't stop at "possible," prove it. Escalate privileges to root. Keep a running findings list. For every confirmed vulnerability record: host, port, service, name, severity (critical|high|medium|low|informational), description, evidence, cve, references, remediation. A finding only counts once you've demonstrated it.

(Dejamos el prompt en inglés porque es el que recibe el agente; funciona igual si lo escribís en español.)

Listo — el agente toma la posta desde ahí: recon, explotación, escalada de privilegios, iterando sobre sus propios errores.

Una nota operativa: los proveedores frontier pueden throttlear o rechazar requests que parecen actividad ofensiva. Para engagements reales, sumá a tu organización al programa de trusted-access del proveedor (Enterprise Trusted Access for Cyber de OpenAI; el proceso de usage-policy de Anthropic) y mantené documentada la autorización. No ofusques la intención para esquivar filtros — no es confiable y te arruina el audit trail.

2. Qué produce realmente una corrida

Acá va una cadena real de una corrida contra la máquina Cache de HackTheBox — el tipo de salida que te devuelve, condensada:

• Recon → http://10.129.1.52/jquery/functionality.js filtra credenciales hardcodeadas ash:H@v3_fun; la enumeración de vhosts saca a la luz la app HMS basada en OpenEMR en hms.htb.
• Bypass de auth + SQLi (CVE-2018–15152, CVE-2019–3964) → el flujo de registro del portal de pacientes de OpenEMR saltea la autenticación; una SQL injection en add_edit_event_user.php (param eid) dumpea la tabla users_secure — el hash del admin, crackeado offline.
• RCE (CVE-2019–8377) → un file-write PHP autenticado vía manage_site_files.php deja una webshell y da ejecución de comandos en el host.
• Credenciales en texto plano en memcached (:11211) → get user / get passwd devuelven luffy:0n3_p1ec3; SSH como luffy → user flag.
• Privesc (grupo docker) → luffy está en el grupo docker, así que docker run -v /:/mnt --rm ubuntu cat /mnt/root/root.txt lee la flag como root → root flag.

Multi-paso, encadenado, y cada eslabón demostrado en vez de supuesto. Ese es el valor que un pentester con IA suma por encima de un scanner — pero ahora mismo está atrapado en un transcript. Arreglemos eso.

3. Mandá los hallazgos a Faraday

Primero apuntá a tu Faraday (self-hosted Community o hosteado Personal — cómo obtener cada uno está al final):

export FARADAY_URL="https://scan.apps.faradaysec.com"   # o http://localhost:5985
export FARADAY_TOKEN="<tu-api-token>"

Ahora hacé el puente con los hallazgos. Elegí el que te sirva.

Puente A — push directo a la API de Faraday

Faraday ingesta hallazgos en una sola llamada. Pasale al agente el endpoint, el token y la forma del payload, y dejá que haga el POST — un prompt de seguimiento en la misma sesión:

Push every confirmed finding to Faraday. POST to $FARADAY_URL/_api/v3/ws/htb-cache/bulk_create with headers Authorization: Token $FARADAY_TOKEN and Content-Type: application/json. Group vulnerabilities by host IP. Body shape: {"hosts":[{"ip":"<ip>","hostnames":["<host>"],"vulnerabilities":[{"name":"...","desc":"...","severity":"high","type":"Vulnerability"}]}]} severity ∈ critical|high|medium|low|informational.

La misma llamada a mano, de referencia:

curl -sS -X POST "$FARADAY_URL/_api/v3/ws/htb-cache/bulk_create" \
  -H "Authorization: Token $FARADAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "hosts": [{
      "ip": "10.129.1.52",
      "vulnerabilities": [{
        "name": "OpenEMR Authenticated RCE (CVE-2019-8377)",
        "desc": "Auth bypass (CVE-2018-15152) + SQLi (CVE-2019-3964) recover admin creds; authenticated file-write yields RCE; chained to root via cleartext memcached creds and the docker group.",
        "severity": "critical",
        "type": "Vulnerability"
      }]
    }]
  }'

Puente B — generá un CSV revisable primero

¿Preferís un gate humano antes de que algo toque Faraday? Que el agente escriba un CSV, lo mirás, y después lo importás:

Output all confirmed findings as CSV with exactly these columns: host,name,severity,description,cve,references. One row per vulnerability, severity ∈ critical|high|medium|low|informational, quote any field containing a comma. Output only the CSV.

pip install faraday-cli
# auth por token: sembrá el archivo de config (faraday-cli auth no tiene flag --token)
printf 'auth:\n  faraday_url: %s\n  token: %s\n' "$FARADAY_URL" "$FARADAY_TOKEN" > ~/.faraday-cli.yml
faraday-cli tool report findings.csv -w htb-cache

Puente C — conectá vía el MCP de Faraday

Si tenés un servidor MCP de Faraday enganchado a tu agente, saltate archivos y HTTP por completo — la misma sesión que encuentra el bug lo registra:

Using the connected Faraday MCP server, create each confirmed finding as a vulnerability in workspace htb-cache, setting name, severity, description, and evidence.

(Confirmá que el servidor MCP de Faraday está disponible en tu setup antes de apoyarte en este puente.)

4. Velo en Faraday

Abrí el workspace htb-cache. Los hallazgos ahora están deduplicados, ordenados por severidad y —esta es la parte que importa— permanentes. Volvé a correr la máquina el mes que viene y Faraday reconcilia contra lo que ya está en vez de crear duplicados, así podés saber de verdad si un fix aguantó.

5. El verdadero payoff: el pentest con IA al lado de toda otra fuente de vulns

Una cadena de exploit confirmada es potente, pero es una sola lente. Tus scanners estáticos ven código que nunca alcanzaste en runtime; tu SCA ve dependencias vulnerables; tu pipeline de DevSecOps ve IaC y secrets. Cada uno es ruidoso y amplio; el pentest con IA es preciso y profundo. Su valor se potencia solo cuando aterrizan en el mismo lugar.

faraday-cli habla los formatos que tu stack ya emite — importalos al mismo workspace:

faraday-cli tool report semgrep.sarif  -w htb-cache   # SAST
faraday-cli tool report trivy.json     -w htb-cache   # SCA / containers
faraday-cli tool report nuclei.json    -w htb-cache   # DAST
faraday-cli tool report burp.xml       -w htb-cache

Ahora un solo workspace responde la pregunta que ninguna herramienta sola puede: de todo lo que sabemos que está mal, ¿qué probó un atacante que podía explotar de verdad? El SAST marca cien sinks; el pentest con IA muestra cuál se volvió RCE. El SCA lista cuarenta paquetes vulnerables; el pentest muestra cuál era alcanzable y se encadenó hasta root. Esa correlación — amplitud de los scanners, prueba del pentester con IA, todo deduplicado y priorizado — es la diferencia entre una pila de hallazgos y un programa de seguridad.

6. Dónde van los hallazgos: Community o Personal

Los dos destinos toman exactamente los mismos comandos de arriba — elegí dónde querés que viva la data.

Faraday Community — gratis, self-hosted, open source. Correlo en tu propia máquina (default http://localhost:5985) y sacá un API token desde la config de tu usuario:

export FARADAY_URL="http://localhost:5985"
export FARADAY_TOKEN="<tu-community-api-token>"

Faraday Personal — hosteado, nada que correr. Creá tu tenant en scan.faradaysec.com; tu instancia vive en scan.apps.faradaysec.com:

export FARADAY_URL="https://scan.apps.faradaysec.com"
export FARADAY_TOKEN="<tu-personal-api-token>"

Corré el pentest con la consola que ya usás, hacé el puente de los hallazgos, y triageálos junto a todo lo demás que sabés. El operador es la IA; el sistema de registro es Faraday.

Probá FaradAI

Todo esto — el pentest autónomo, la validación de explotabilidad y el triage — es FaradAI, corriendo dentro de Faraday. En vez de armar el flujo a mano, dejá que un agente ofensivo autónomo pentestee cada target y te deje los hallazgos priorizados en un solo lugar.

👉 Conocé FaradAI: faradaysec.com/faradai

Dale a tu pentester con IA un hogar para sus hallazgos — Faraday Community · Faraday Personal →

Manos a la obra: Pentest con Claude/Codex → Faraday was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scanners have never been the bottleneck. Finding vulnerabilities is the easy part now — an agent can surface more exploitable issues in an afternoon than a team can triage in a week. The bottleneck is everything after the finding: validating it’s real, prioritizing it, and actually fixing it fast enough to hold an SLA while the backlog grows.

This post is about closing that loop on AWS end to end: AWS’s Security Agent finds it, FaradAI runs its own autonomous pentest and then proves, chains and triages every finding, and AWS Systems Manager patches it — with the prevention steps that stop it coming back. And because AWS Security Agent ships with a 2-month free trial (up to 400 task-hours/month), you can run the entire loop before spending a dollar (see §8).

1. Two agentic layers, then a fix

The old model was one scanner throwing a wall of CVEs over the fence. The new model is a pipeline of agents, each doing one thing well:

AWS Security Agent scans the AWS environment
   ↓   findings imported via Faraday's aws_security_agent connector
FaradAI runs its OWN autonomous pentest + validates and chains the Security Agent findings
   ↓   proves real exploitability with working PoCs
FaradAI triage: enrich, dedup, prioritize, SLA-tag — one workspace
   ↓
AWS Systems Manager applies the fix (patch / automation runbook)
   ↓
Prevent: key hygiene, IMDSv2, IaC — so it doesn't regress

Why two offensive layers instead of one? They’re complementary — and they cross-check each other:

• AWS Security Agent — Native visibility into the AWS environment; surfaces exploitable vulnerabilities with far less noise than a traditional scanner (Inspector/Tenable-style)
• FaradAI — Runs its own autonomous pentest against the target and takes the Security Agent findings further — chaining them, proving exploitability with working PoCs — then does the triage: enrichment, screenshots, deduplication, consolidation into one workspace

The Security Agent tells you what’s wrong on AWS. FaradAI attacks it itself — running an autonomous pentest — and tells you which findings (its own and the Security Agent’s) an attacker can actually use, turning each into a prioritized, evidence-backed, ticketable item.

2. Connect the AWS infra — the right way

Before anything scans, it needs access to the environment. The single most important choice here is how you grant it — because static AWS access keys are one of the most common root causes of real incidents.

• Use an IAM role with temporary credentials, not long-lived access keys. Assume-role / OIDC federation for the scanner and for FaradAI’s runners; no static secrets sitting in a config.
• Scope it tightly — read/enumerate for scanning, and a separate, narrowly-scoped role for the remediation step (more on that below).
• Authorize the scope explicitly. When scanning domains, validate ownership with a DNS record so the activity is clearly authorized — both for your own audit trail and for AWS Trust & Safety when third-party hosts are in play.

3. Pull Security Agent findings in — the connector

You don’t scrape a dashboard or export a CSV. Faraday ships an official aws_security_agent connector (a dispatcher executor) that talks straight to AWS's Security Agent service — the boto3 securityagent client — and imports its results as Faraday vulnerabilities. It walks the service the way the API is laid out (ListAgentSpaces → ListPentests → ListPentestJobsForPentest → BatchGetFindings + ListDiscoveredEndpoints) and maps each finding, with its riskLevel, into the workspace.

Crucially, it authenticates the way Section 2 argued for: the connector uses the dispatcher’s IAM role by default — you leave the AWS key fields blank and let the container’s role (or STS AssumeRole) supply short-lived credentials. No static access keys anywhere in the loop.

Run it like any Faraday agent:

faraday-cli agent run \
  -a "$DISPATCHER_AGENT_ID" \
  -e aws_security_agent \
  -w aws-prod-<date> \
  -p '{
    "AWS_REGION": "us-east-1",
    "AWS_SECURITY_AGENT_AGENT_SPACE": "as-<uuid>",
    "AWS_SECURITY_AGENT_MODE": "findings,endpoints"
  }'

Leave AWS_SECURITY_AGENT_AGENT_SPACE off to sweep every agent space in the account, or pin AWS_SECURITY_AGENT_PENTEST_ID / _JOB_ID to import one run. The Security Agent's findings are now Faraday vulns, in a workspace, ready for the next layer.

4. Autonomous pentest + triage with FaradAI

FaradAI runs as a Faraday Cloud Agent against the same targets, in two executions — first the pentest, then the triage. Cloud Agents are triggered over the REST API with curl (they aren't driven by faraday-cli); grab each agent's id from Cloud Agents in the UI or GET /_api/v3/cloud_agents.

First execution — the autonomous pentest

It does two things in one pass: an autonomous pentest of its own (recon → attack → chain → prove), and validation of what the Security Agent already surfaced:

curl -sS -X POST "$FARADAY_URL/_api/v3/cloud_agents/$FARADAI_AGENT_ID/run" \
  -H "Authorization: Token $FARADAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "args": {
      "TARGET": "<in-scope AWS host / app>",
      "INSTRUCTION": "Run a full autonomous pentest of the target; also validate and chain the Security Agent findings already in the workspace; prove exploitability with working PoCs",
      "MODE": "Dual",
      "ROUNDS": 40,
      "DRY_RUN": false,
      "TIME_LIMIT_SECONDS": 86400
    },
    "workspaces": ["aws-prod-<date>"]
  }' -w "\nHTTP %{http_code}\n"

The call is fire-and-forget: it returns immediately (HTTP 200 with a command_id and runner id) while the pentest runs in the background. FaradAI works its rounds — with shared memory across passes and human-in-the-loop steering when you want it — finding new attack paths on its own while corroborating the Security Agent's, and pushing every proven finding into the workspace.

Second execution — triage the whole workspace

A separate call points FaradAI’s triage Cloud Agent at the same workspace, so it enriches, deduplicates and prioritizes everything together — the Security Agent findings and FaradAI’s own pentest results:

curl -sS -X POST "$FARADAY_URL/_api/v3/cloud_agents/$FARADAI_TRIAGE_AGENT_ID/run" \
  -H "Authorization: Token $FARADAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "args": {
      "WORKSPACE_NAME": "aws-prod-<date>",
      "MODE": "Dual",
      "PATCHING_MODE": "dry-run"
    },
    "workspaces": ["aws-prod-<date>"]
  }' -w "\nHTTP %{http_code}\n"

WORKSPACE_NAME is what gets triaged. Triage adds screenshot evidence, dedupes across both sources, and ranks by validated exploitability — turning a pile of findings into a prioritized queue of proven issues, each with the evidence a fix owner needs. PATCHING_MODE stays dry-run here because on AWS we apply the actual fix with Systems Manager (next section); flip it to apply only if you want FaradAI itself to drive the remediation.

5. One workspace: next to the DevSecOps findings you already collect

The Security Agent findings and FaradAI’s pentest now live in one workspace — but your team is already producing more: SAST on the source, SCA on dependencies, secret and IaC scanning in CI, CSPM on the account. Those belong in the same place, not in four separate dashboards.

faraday-cli speaks the formats your stack already emits, so import them into the same workspace:

faraday-cli tool report semgrep.sarif  -w aws-prod-<date>   # SAST
faraday-cli tool report trivy.json     -w aws-prod-<date>   # SCA / containers / IaC
faraday-cli tool report gitleaks.json  -w aws-prod-<date>   # secrets
faraday-cli tool report prowler.json   -w aws-prod-<date>   # AWS posture (CSPM)

Now one workspace answers the question no single tool can: of everything we know is wrong — across AWS, the code, and the dependencies — what did an attacker actually prove they could exploit? Prowler flags a hundred posture issues; FaradAI shows which one chained to an IAM-role takeover. The SCA lists forty vulnerable packages; the pentest shows which one was reachable and led to RCE. That correlation — breadth from the scanners, proof from FaradAI and the Security Agent, all deduplicated and prioritized — is what turns a pile of findings into a security program, and it’s what feeds the patch step next.

6. Triage → patch with Systems Manager

This is the step that actually moves the SLA needle. FaradAI’s triage output drives AWS Systems Manager, which already has the reach to change the fleet. Two flavors, matched to the finding type:

OS / package CVEs → Patch Manager. For a vulnerable package on EC2, run the managed patch baseline against the affected instances:

aws ssm send-command \
  --document-name "AWS-RunPatchBaseline" \
  --parameters "Operation=Install" \
  --targets "Key=InstanceIds,Values=i-0abc123,i-0def456"

Misconfigurations → Automation runbooks. For the exposure-class findings FaradAI validates, trigger an SSM Automation document (or a direct API call) that fixes the specific condition:

# Enforce IMDSv2 on an instance that leaked role creds via SSRF
aws ec2 modify-instance-metadata-options \
  --instance-id i-0abc123 --http-tokens required --http-put-response-hop-limit 1

# Block public access on an exposed bucket
aws s3api put-public-access-block --bucket acme-prod-backups \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

The remediation role stays separate and minimally scoped, so the thing that finds problems is never the thing that can change production. FaradAI proposes the fix and the evidence; the SSM action applies it against the exact resources named in the finding; a re-scan confirms it’s closed. That’s the automated slice of patching that keeps SLAs intact as volume climbs.

Automate with a guardrail. Auto-apply the safe, well-understood fixes (patch baselines, public-access blocks, IMDSv2); gate the riskier ones behind human approval. The point isn’t to remove people — it’s to stop them being the bottleneck for the obvious 80%.

7. Prevent, don’t just cure

Patching the instance is the cure. Prevention is what stops the same finding reappearing on the next deploy:

• Kill static access keys. Rotate what exists, move to temporary credentials and roles. This is the highest-leverage prevention on AWS, full stop.
• Enforce IMDSv2 at launch (in the launch template / AMI), not just reactively per instance.
• Push the fix into IaC. For anything that came from Terraform or CloudFormation, land the remediation as a pull request so the corrected state is the default next time — cure becomes prevention.

8. Cost — and how to run the whole loop for free

You can prove this entire workflow at zero cost, because AWS Security Agent (on-demand penetration testing) ships with a 2-month free trial for new customers:

• Up to 400 task-hours of pentesting per month, free, for the first 2 months.
• Design reviews (up to 200/month) and code reviews (up to 1,000/month) at no additional cost.
• After the trial — or once you exceed the limit — it’s $50 USD per task-hour.

400 task-hours a month is a lot of runway: more than enough to stand up the vulnerable lab below, run Security Agent + FaradAI’s autonomous pentest + triage + Systems Manager end to end, and tune the loop before you spend anything. FaradAI’s own pentest and triage run on your Faraday instance (Personal), so the AWS trial covers the cloud-side scanning while you validate the full workflow.

(Pricing per AWS as of publication — confirm the current numbers on the AWS Security Agent pricing page before you plan around it.)

Try FaradAI

Everything here — the autonomous pentest, the exploitability validation, the triage — is FaradAI, running inside Faraday. Instead of wiring the flow by hand, let an autonomous offensive agent pentest every target and hand you the prioritized findings in one place.

👉 Meet FaradAI: faradaysec.com/faradai

Give your AI pentester a home for its findings — Faraday Community · Faraday Personal →

From Scan to Patch on AWS — Security Agent + FaradAI, End to End was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

Faraday es una empresa de ciberseguridad que nació como una herramienta open source. Hoy, once años después, ayudamos a cientos de equipos en todo el mundo con nuestras versiones gratuitas y comerciales. Pero en sus inicios, Faraday era solo un proyecto libre, accesible para cualquier persona interesada en mejorar sus procesos de seguridad. En ese camino, Kali Linux fue clave.

Kali es una distribución de Linux que le facilitó a muchas personas dar no sólo los primeros pasos en ciberseguridad sino también en Linux. ¿Qué significa? Que era una distribución pensada y focalizada en tener un conjunto de herramientas curadas y seleccionadas por profesionales de la seguridad en un solo lugar. Lo que facilitaba mucho las tareas de seguridad. Al haber un sin número de herramientas muy específicas, muchas veces la instalación se hacía difícil. Y mucha gente se frustraba en el proceso. Kali profesionaliza esta curaduría de herramientas y genera una plataforma accesible y gratuita para cualquier persona interesada en seguridad, acompañando tanto a quienes recién empiezan como a profesionales con años de experiencia.

En general, ya existían un sinfín de herramientas. Lo que hizo Kali fue unificarlas en una sola plataforma. Para quienes trabajaban con seguridad Wi-Fi o necesitaban módulos de kernel específicos, Kali se convirtió en el denominador común. Era el lugar donde todas esas herramientas estaban preinstaladas, organizadas y listas para usar. Podías encontrar desde herramientas clásicas como Metasploit, hasta otras de red team como Empire, o utilidades web como DirBuster. Y entre ellas, muchas veces, estaba Faraday.

Nuestro camino con Kali siempre fue muy interesante. Ser incluidos como una de las herramientas curadas por el equipo de Offensive Security fue una validación enorme. Significó que nuestro trabajo había alcanzado un nivel de madurez y podía ser útil para una comunidad global. De pronto, estábamos en la barra de iconos, y mucha gente nos descubría desde ahí.

Fue una etapa de mucha exposición: de un día para el otro, cientos (y luego miles) de personas empezaron a usar Faraday. Para un equipo chico como el nuestro, eso fue tanto una alegría como un desafío. Tuvimos que robustecer nuestros procesos, automatizar pruebas, mejorar el build, y asegurar compatibilidad con cada nueva versión de Kali. Ese feedback masivo nos ayudó a evolucionar mucho más rápido.

También nos permitió estar en contacto con otros desarrolladores de herramientas como nosotros. A veces, al presentar Faraday, alguien nos decía: “Ah, el que está en Kali”. Y sí, eso abría puertas, nos conectaba con gente con intereses y valores similares.

En los últimos años, decidimos invertir más en nuestra versión Community. Sumamos funcionalidades que antes eran exclusivas del producto comercial, como los agentes para automatizar el trabajo del pentester. Porque creemos sinceramente en el valor del open source: en dar acceso sin barreras, en que cualquiera pueda aprender, experimentar, mejorar y contribuir.

El open source es parte de nuestro ADN. Creemos en la transparencia, en que el usuario pueda ver cómo funciona una herramienta, modificarla y adaptarla a sus necesidades. Muchas personas en nuestra comunidad crecieron profesionalmente gracias al open source, y poder aportar de vuelta a ese ecosistema es una satisfacción enorme.

Trabajar con Kali nos exigió subir la vara, mejorar nuestros procesos de desarrollo, estar siempre atentos a los cambios, mantener el contacto con su equipo y con la comunidad. A lo largo del tiempo, hemos tenido todo tipo de experiencias: desde picos de descargas inesperados tras una nueva versión, hasta colaboraciones con desarrolladores de herramientas icónicas.

Kali fue y es una puerta de entrada para miles de personas a la ciberseguridad. Que Faraday forme parte de esa experiencia, que alguien nos descubra mientras estudia para una certificación o configura su primer laboratorio, es algo que nos llena de orgullo.

Once años después, seguimos con la misma convicción. Y seguimos agradecidos de formar parte de una comunidad que valora lo abierto, lo compartido y lo colaborativo. Kali es un punto de encuentro para una forma de hacer seguridad que compartimos y en la que creemos profundamente.

Puede visitar nuestro proyecto open source.

11 años de ciberseguridad: Kali y Faraday. Crecer en comunidad, crecer en ciberseguridad was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

Este artículo tiene como objetivo combinar la automatización y metodologías de pentesting de forma práctica, usando inteligencia artificial y múltiples herramientas opensource. Más que un simple repaso de comandos, se trata de compartir una metodología replicable, flexible y accesible.

El enfoque que queremos mostrar es como con las herramientas que hoy en día son públicas y con ayuda de modelos de IA es posible mejorar procesos automáticos donde no se requiera tiempo manual y dedicarlo justamente a aspectos de explotación y, por que no, algo más divertido.

El enfoque del atacante

Lo ideal en esta primera parte, es pensar como un atacante. Partamos desde una situación típica: tenemos el dominio de una empresa, por ejemplo evilcorp.com, y desde ahí, empecemos a ampliar nuestra superficie de ataque:

• Reconocimiento de subdominios
• Análisis de puertos
• Análisis de servicios
• Búsqueda de vulnerabilidades
• Reporte de lo identificado

El orden no es casual. Primero se amplía la superficie de ataque, después se avanza en técnicas más activas, y finalmente se busca vulnerabilidades concretas que puedan ser explotadas.

Expansión de superficie de ataque

Cuando comenzamos un nuevo proyecto, solemos estar a ciegas. Por eso, existen muchas herramientas que nos ayudan a hacer los primeros descubrimientos y nosotros usaremos assetfinder:

Sigamos con el ejemplo de antes (tomando a nuestra compañía evilcorp), y entendamos que no solo tenemos que limitarlos a evilcorp.com, sino contemplar toda su superficie (subdominios, servicios, direcciones IP, registros DNS). El objetivo es ampliar lo máximo posible la superficie de ataque antes de pasar a etapas más activas.

Hay un sinfín de herramientas que podemos utilizar como por ejemplo bbot, subfinder, sublist3r entre otras, que resultan ideales para proyectos blackbox (donde tengo poco conocimiento del objetivo). Por ejemplo, bbot tiene la particularidad de retroalimentarse: va encontrando subdominios, luego IPs, y sigue expandiendo automáticamente la información disponible.

En esta demo nos vamos a centrar en assetfinder y usaremos el parámetro –subs-only, lo que rápidamente arroja una larga lista de subdominios. Acá es donde podemos hacer nuestra primera observación:

Si bien hay nuevos subdominios, notamos que existen varios duplicados o registros que no resuelven correctamente. Por eso, es clave filtrar y quedarse solo con lo que realmente sirve.

Escaneo de puertos

Una vez identificados los subdominios, el siguiente paso es analizar qué servicios están expuestos a través de ellos. Tal como vimos antes existen varias herramientas que podemos usar::

• masscan
• naabu
• nmap

Nosotros en nuestro caso vamos a usar Nmap con los parámetros:

• –top-ports 100 (solo los 100 puertos más conocidos) de puertos más comunes
• -Pn (para que no solo haga pruebas por ICMP/ping)
• -iL [hosts.txt] (donde le pasamos una lista de hosts separados por saltos de línea)
• open (para ver solo resultados de puertos abiertos)

Nuevamente, como vemos en el video, tenemos errores que nos indican algunos puntos de mejora:

• Varios dominios no resolvieron.
• Quizás sea mejor utilizar IPs en lugar de subdominios.

Entender qué estamos analizando

Un paso útil, por lo menos en esta etapa, es limitar la cantidad de falsos positivos al momento de querer analizar alguna aplicación web, donde podemos utilizar por ejemplo httpx para validar si la URL que tenemos responde a un puerto web (80/443). Esto validará que las aplicaciones sean reales, y que en caso de querer analizarla sepamos con anticipación que el servicio está corriendo sin problemas.

También, podríamos plantear un escenario en el que nuestro scanner de puertos reciba una entrada de direcciones IP directamente, ya que en algunos casos no logra resolver o analizar los dominios asociados. Para eso, podemos usar un oneliner como el que mostramos debajo y donde a partir de un archivo txt de subdominios, podemos resolver las direcciones IPs que resuelven (para luego ser pasadas por ejemplo a nmap).

¿Y ahora?

Ya teniendo una lista depurada de IPs, dominios, subdominios validados y confirmados, podemos pasar a la etapa de análisis de vulnerabilidades, donde de nuevo, muchas herramientas opensource nos pueden ayudar:

• OpenVAS (mas centrado en infraestructura)
• nuclei
• nikto (mas centrado en web)

En nuestro caso, vamos a centrarnos por nuclei por la versatilidad que tiene, ya que permite ejecutar muchas pruebas (y variadas) en poco tiempo, utilizando templates que detectan desde configuraciones incorrectas de seguridad como vulnerabilidades específicas como paneles expuestos, versiones obsoletas de software o endpoints con respuestas interesantes (por ejemplo, backups expuestos).

Ahora bien, el problema aparece cuando el escaneo genera cientos de findings. ¿Cómo priorizamos? ¿Cómo transformamos eso en algo útil para el equipo de seguridad o para la gerencia? Acá es donde la inteligencia artificial empieza a cumplir un rol clave. Utilizando modelos como GPT — ya sea a través de servicios como OpenAI o ejecutando modelos locales como los que ofrece Ollama — podemos analizar esos resultados, agruparlos por criticidad, generar explicaciones legibles para no técnicos e incluso proponer posibles soluciones.

Esto no es teoría: hoy ya se están generando informes automáticos que convierten 200 findings técnicos en un resumen de dos páginas, con riesgos priorizados, impacto estimado y un lenguaje entendible para áreas de negocio. Incluso se pueden producir dos versiones del mismo reporte: una técnica para el equipo de infraestructura, y otra ejecutiva para el CISO o el board.

El verdadero poder está en la automatización del flujo completo: desde la entrada con una lista de dominios, pasando por la resolución de IPs, el escaneo con Nuclei, el análisis de resultados con IA, hasta la generación automática del reporte final. Todo esto puede integrarse con scripts en Bash o Python, tareas programadas con cron, pipelines que corren al recibir una nueva lista de targets o tras una alerta en el SIEM. Lo importante no es solo que sea automático, sino que esté pensado para escalar sin perder contexto.

Y como toda buena automatización, siempre hay un espacio para la revisión manual. Porque la IA puede sugerir, pero quien decide es el analista. Lo valioso no es solo el código o las herramientas, sino cómo diseñamos el flujo, cómo elegimos qué automatizar y dónde seguimos aportando criterio humano.

Automatizar no es reemplazar al analista, es permitirle enfocarse en lo que realmente importa. ¿Qué parte de tu flujo podrías automatizar mañana mismo?

Mirá la charla completa acá

Gabriel Franco

Gabriel Franco, quien lidera el área de servicios de seguridad en Faraday, cuenta que su formación viene del mundo técnico, específicamente desde el desarrollo. Su primer acercamiento al pentesting fue justamente desde ese ángulo: crear scripts y automatizaciones para ejecutar herramientas de análisis y ahorrar tiempo, con el foco puesto en obtener resultados más rápido y de forma más efectiva.

Con el tiempo, fue tomando roles de mayor gestión, pero sigue involucrándose en tareas técnicas, sobre todo cuando encuentra algo que se puede mejorar o automatizar. Explica que dentro del equipo siempre están atentos a los patrones que se repiten entre distintos proyectos. Cuando detectan tareas que se reiteran, buscan automatizarlas para concentrarse en lo que realmente agrega valor.

Trainings, red teaming services, or continuous scanning?

We’ve got you covered. 🚀⚡

Reach out for more information.

Automatización y Pentesting: Usa la IA y herramientas Open-Source was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

In our last two posts, we introduced our open-source and modular CAN Bus — USB adapter called Doggie and shared our experience at the Car Hacking Village of the H2HC conference, where we used Doggie to show attendees the inner workings of CAN Bus Networks.

This post will explore a practical use case to demonstrate Doggie’s power in automotive security research. Imagine you need to unlock a vehicle by sending the correct sequence of CAN messages. With Doggie and tools like Python-can, can-utils, or custom scripts, you can sniff unlocking messages, replay them, and even experiment with manipulating the system for security analysis.

In this case study, we’ll walk through how to use Doggie to sniff and inject messages into the CAN Bus of a 2010 Jeep Liberty. The setup consists of Doggie with the RP2040 and MCP2515 configuration, which provides the interface between the car’s CAN Bus and your computer.

Step 0: Introduction to CAN Bus and Message Structure

Before diving into the practical case study, it’s important to understand the basic structure of a CAN Bus frame. A CAN frame typically consists of several components:

1. Start of Frame — Marks the beginning of the message.
2. Identifier (ID) — A unique ID for the message, which determines its priority in the bus.
3. Control Field — Includes the length of the data field.
4. Data Field — Contains the actual message data, which can range from 0 to 8 bytes.
5. CRC — A checksum used to detect errors in the message.
6. ACK — The acknowledgment field is where the receiving nodes confirm the successful reception of the message.
7. End of Frame — Marks the end of the message.

For this post, we won’t discuss the intricacies of how the CAN Bus works at the electrical level or explore its protocol in depth. Instead, we will focus on the practical use of Doggie for sniffing, analyzing, and injecting messages, leaving detailed electronics and hardware explanations aside. Our goal is to demonstrate how to use Doggie to interact with CAN Bus networks. For a more profound exploration of the CAN Bus protocol, we recommend consulting additional resources on the subject.

Step 1: Research and Documentation

Before jumping into the physical connections, the first step is to gather relevant documentation about the car, especially the “Repair Manual” and the “Wiring Diagram.” These documents may not be perfectly detailed, but they provide crucial information on the car’s electrical system, modules, and communication buses. In this case, we found a helpful diagram that outlines the key CAN buses in the Jeep Liberty.

As shown in the image, the car contains three primary CAN buses:

• CAN C Bus
• Diagnostic CAN C Bus
• CAN Interior Bus

Each bus operates at its own speed and communicates with different modules. A key piece of information here is that all the buses connect to the TIPM (Totally Integrated Power Module), also known as the Common Gateway for Communication (CGW). This module acts as a gateway to manage communication between different buses, ensuring that messages from OBD2 diagnostic systems are isolated from other buses, such as those handling door locks or brakes.

Step 2: Finding the Right Bus and Module

We focus here on the Driver Door Module (DDM) and Passenger Door Module (PDM). According to the diagram, both modules are connected to the CAN Interior Bus. To access this bus, we needed to locate an appropriate connection point. We identified that the seat memory module is also connected to this bus and conveniently located under the seat.

We then used the Repair Manual to identify CAN High and CAN Low wires. The diagram showed that the white and orange cable is CAN Low, and the white and gray cable is CAN High.

To validate our connection further, we used an oscilloscope to check the signals on the bus. We connected the oscilloscope to the CAN High and CAN Low lines to ensure the signals were correct for CAN Bus communication.

Step 3: Setting Up Doggie

Once the hardware connections were in place, we connected Doggie to the CAN bus and the computer. First, we installed the can-utils package on Linux:

$ sudo apt-get install can-utils

Next, we set up the CAN interface for Doggie. We know from the diagram that the bus operates at 125kbps, so we used the following command to start the slcan daemon and initialize the CAN interface:

# Start the slcan daemon and set up the interface

$ sudo slcand -s4 /dev/ttyUSB0 can0 && sudo ifconfig can0 up

After this setup, we had a CAN interface named can0 that was ready to interact with the car’s bus.

Step 4: Sniffing CAN Messages

We used the cansniffer tool to start sniffing messages on the bus. This tool helps identify interesting messages by highlighting changes in data. This is especially useful during live interactions, such as locking or unlocking the doors.

$ cansniffer -c can0

Once we started sniffing, we triggered events, such as locking and unlocking the doors. In the video, a new message appears with the ID 0x3ED every time we press the lock button. This tells us that 0x3ED is the ID responsible for door lock/unlock commands.

Step 5: Interpreting the Messages

While cansniffer shows data differences, it’s not always the best tool for analyzing message details because it overwrites previous information. Instead, we used candump with an ID filter to focus on the specific messages relevant to locking and unlocking.

$ candump can0,0x3ED

We observed three distinct messages:

• 0x20: Sent periodically, likely a liveness message.
• 0x30: Sent when locking the doors.
• 0x28: Sent when unlocking the doors.

Once we understood the message structure, we could proceed to inject messages.

Step 6: Injecting Messages

To lock or unlock the doors, we used cansend to inject the corresponding message. Here’s how we sent the unlock command:

$ cansend can0 3ED#28

In the demo video, we can see the doors lock and unlock based on the messages we sent.

Doggie represents Faraday’s commitment to empowering the community with tools that democratize automotive cybersecurity research. Whether you’re a seasoned professional or a newcomer to car hacking, Doggie provides a low-cost, versatile solution to explore CAN Bus networks and beyond.

Check out the project on GitHub!

Check out the rest of the car hacking articles:

PART 1

PART 2

Trainings, red teaming services, or continuous scanning? We’ve got you covered. 🚀⚡

Reach out for more information.

Case Study: Unlocking a Car Using Doggie was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our previous post introduced Doggie, an open-source and modular CAN Bus — USB adapter designed to simplify working with CAN Bus networks, enabling secure exploration and development in the automotive space.

Last month, Doggie took the stage at the Car Hacking Village during the H2HC conference on December 13th and 14th in São Paulo. This exciting village featured various presentations and workshops exploring the world of automotive security. The Faraday team showcased Doggie in a uniquely interactive way, allowing attendees to dive into CAN Bus exploration hands-on.

To create an engaging experience, we developed a simulated environment with a working CAN Bus network, enabling participants to interact using Doggie or their own hardware. This environment consisted of two main components:

1. A PC running the CARLA simulator
   CARLA is a highly realistic car simulator often used to train and test autonomous vehicle algorithms. In our setup, CARLA connected to the CAN Bus via Doggie.
2. A Raspberry Pi with a game controller
   The Raspberry Pi acted as a bridge between the controller and the CAN Bus. It interpreted button presses on the controller, translated them into control commands, and used Doggie to send them over the CAN Bus.
3. The communication flow worked like this:

• A user pressed buttons on the controller, which the Raspberry Pi interpreted as commands.
• The Raspberry Pi sent these commands over the CAN Bus via Doggie.
• The PC received the commands, interacted with the CARLA simulator, and executed the corresponding actions (e.g., throttle, steering, opening doors, or switching lights).

In short, we created a CAN Bus controller and a CAN Bus interface for the CARLA simulator and seamlessly connected them.

Participants had the opportunity to control the simulated car using the controller while also experimenting with the CAN Bus. They could:

• Reverse engineer messages on the bus.
• Inject commands into the bus to manipulate the simulator.
• Cause the car to crash while another person was driving.
• Unlock the simulated car’s doors.
• Explore countless other creative scenarios.

We deliberately kept the messages simple to ensure that even beginners could follow along, understand the basics of CAN Bus communication, and learn with us in real-time.

The setup was a huge success, attracting many visitors eager to learn, chat, and play. From reverse engineering enthusiasts to curious beginners, everyone left with a deeper understanding of CAN Bus and Doggie’s potential.

For those who couldn’t attend, we’ve made the entire setup available online! You can find the repository with all the scripts and tools you need to recreate the experience yourself.

Trainings, Vulnerability Management, Red Teaming Services, or Continuous Scanning? We’ve got you covered. 🚀⚡

Our Experience at the Car Hacking Village H2HC was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

At Faraday, we are passionate about advancing the field of cybersecurity. One of our key areas of focus is Car Hacking Research. Since the early 2000s, vehicles have evolved from purely electro-mechanical machines to complex computer networks on wheels. Modern cars contain over 100 million lines of code — more than some commercial aircraft. As vehicles become increasingly connected and reliant on electronic systems, understanding and securing these systems is more relevant than ever.

To make automotive cybersecurity research more accessible and affordable, we developed Doggie, an open-source and modular CAN Bus — USB adapter. Whether you’re a hobbyist, researcher, or professional, Doggie is designed to simplify working with CAN Bus networks (Controller Area Network), enabling secure exploration and development in the automotive space.

The Importance of CAN Bus in Vehicles

Before delving into Doggie, let’s briefly discuss the Controller Area Network (CAN) Bus, the backbone of modern vehicle communication. CAN Bus can connect critical electronic control units (ECUs) for the engine, brakes, transmission, and even some comfort, information display, and entertainment systems. This network enables seamless communication between these systems, ensuring the vehicle operates efficiently and safely.

For cybersecurity professionals and enthusiasts, CAN Bus represents a critical area for exploration. It offers insights into how vehicles work and the opportunity to secure them against potential threats.

About Doggie

Doggie is a modular, flexible, open-source adapter that bridges the gap between a computer and a CAN Bus network using USB. Built with affordability and adaptability in mind.

Its compatibility with SocketCAN on Linux, Python-can, and other slcan-compatible software ensures seamless integration with existing CAN Bus analysis, sniffing, and injection tools. Doggie also supports ISO-TP, making it perfect for standard and advanced CAN Bus applications. Whether running diagnostics, experimenting with custom in-car functionalities, or performing penetration tests, Doggie provides the tools you need to succeed.

The project emphasizes modularity, allowing users to select from various hardware configurations with different microcontrollers and CAN transceivers. This makes it accessible and cost-effective. Doggie adapts to your needs whether you’re using a microcontroller’s built-in CAN controller or an MCP2515 (SPI to CAN) module.

You can create your own DIY Doggie only by choosing a microcontroller, a CAN interface, and a Serial interface combination. Six possible configurations are available today, and more hardware support is coming!

Microcontrollers:

• Raspberry Pi Pico (RP2040)
• STM32F103C8 (Bluepill)
• ESP32

CAN Controllers:

• Built-in CAN controllers
• MCP2515 (SPI to CAN)

USB/Serial Connectivity:

• Microcontroller USB (native USB support)
• UART with USB Bridge

Doggie’s modular nature and the fact that it was written purely in Rust with hardware abstraction by design make developing new hardware support easy and fast. Thus, if the hardware you already own or prefer is not supported yet, consider adding support for them. It should take a short time and little effort.

Practical Application: Using Doggie in Real-World Scenarios

Doggie isn’t just a tool for research. It’s a versatile companion for real-world automotive applications. Here are some practical scenarios where Doggie can shine:

1. Vehicle Diagnostics

Accessing real-time diagnostic information, including engine parameters, sensor readings, and fault codes. Doggie enables you to interact with the vehicle like a professional-grade diagnostic tool.

2. Customization

Adding new functionalities to your vehicle by sending custom CAN messages. From controlling actuators to integrating new sensors, the possibilities are endless.

3. Security Assessments

Leveraging Doggie to perform penetration testing and vulnerability analysis on vehicle networks. Identify weak points and explore ways to secure critical systems.

Future Work

At Faraday, we are committed to expanding Doggie’s capabilities to meet the growing needs of the automotive security research community. Looking ahead, our plans include:

1. Broader Hardware Support
   Doggie’s modularity is one of its defining strengths, and we aim to make it even more versatile. We are working on extending support to additional microcontrollers, ensuring that users can leverage various platforms for their projects.
2. Wireless Capabilities
   We plan to incorporate wireless communication features to enhance Doggie’s flexibility and ease of use. By leveraging the Bluetooth and Wi-Fi capabilities of microcontrollers like the ESP32, Doggie will enable researchers to interact wirelessly with CAN Bus networks, opening up new possibilities for remote diagnostics, testing, and experimentation.
3. A Dedicated CAN Bus Hacking Edition
   We are also developing a new version of Doggie specifically tailored to the needs of automotive security researchers. This edition will include built-in features to facilitate various CAN Bus attacks, providing researchers with a powerful toolset for studying and exploiting vulnerabilities.

These enhancements will continue to make Doggie an essential tool for anyone looking to explore, understand, and secure CAN Bus systems. We’re excited about the possibilities and can’t wait to share these new developments with the community.

Conclusion

Doggie represents Faraday’s commitment to empowering the community with tools that democratize automotive cybersecurity research. Whether you’re a seasoned professional or a newcomer to car hacking, Doggie provides a low-cost, versatile solution to explore CAN Bus networks and beyond.

Get Involved

Doggie is an open-source project, and we invite you to join our growing community. Visit Doggie to learn more, access the source code, and contribute to the future of automotive security.

Together, let’s drive innovation and secure the roads of tomorrow.

Trainings, red teaming services, or continuous scanning? We’ve got you covered. 🚀⚡

Reach out for more information.

Doggie: A Must-Have Open Source Tool for Car Hacking and Automotive Security was originally published in Faraday on Medium, where people are continuing the conversation by highlighting and responding to this story.