📰 Originally published on Securityelites — AI Red Team Education — the canonical, fully-updated version of this article.
🤖 AI/LLM HACKING COURSE
FREE
Part of the AI/LLM Hacking Course — 90 Days
Day 20 of 90 · 22.2% complete
⚠️ Authorised Targets Only: LLM API reconnaissance — including directory brute-forcing and JavaScript analysis — must only be performed against applications within your authorised scope. Passive traffic analysis and JavaScript review are always within scope; active brute-forcing requires explicit confirmation that it’s permitted in the engagement rules.
On an application security assessment last year, the brief listed one AI feature: a customer-facing chatbot in the bottom-right corner of the website. I spent the first thirty minutes browsing the application with Burp running. By the time I finished, I had fourteen AI-powered endpoints in my HTTP history. The chatbot was endpoint number one. Endpoints two through fourteen were undocumented — an internal document summariser, a lead scoring system, a product recommendation engine, three different content generation tools in the admin panel, and several others. None of them were in the brief. All of them were in production.
The most vulnerable endpoint wasn’t the chatbot. It was the internal document summariser — the one endpoint that accepted uploaded files and had no rate limiting, no authentication requirement for the API path itself (only for the frontend UI that called it), and a system prompt loaded from a configuration file that the frontend team had embedded with the production database read credentials because “the AI needs to look up customer context.” That endpoint wasn’t in the scope document because the client didn’t know it was AI-powered. Reconnaissance is how you find what the client didn’t think to tell you about.
🎯 What You’ll Master in Day 20
Find undocumented AI endpoints through passive traffic analysis and JavaScript extraction
Fingerprint AI backends using response characteristics, timing, and error patterns
Identify AI-powered endpoints in JavaScript bundles using automated extraction
Map the data flow from user input to AI context for each discovered endpoint
Assess authentication and rate limiting gaps per AI endpoint
Build a prioritised test scope document from reconnaissance output
⏱️ Day 20 · 3 exercises · Kali Terminal + Think Like Hacker + Kali Terminal ### ✅ Prerequisites - Day 17 — Burp Suite for LLM Testing — the Burp proxy setup from Day 17 is the primary tool for passive traffic analysis in Day 20 - Basic familiarity with JavaScript bundle analysis — searching minified JS for API route strings - Python with requests and BeautifulSoup installed — used in Exercise 1’s automated endpoint detection ### 📋 LLM API Reconnaissance — Day 20 Contents 1. Passive Discovery via Traffic Analysis 2. AI Backend Fingerprinting 3. JavaScript Bundle Analysis for Undocumented Endpoints 4. Authentication and Access Control Assessment per Endpoint 5. Data Flow Mapping from Input to AI Context 6. Building the Prioritised Test Scope Document Days 16 through 19 assumed you already knew which AI endpoints to test. Day 20 covers how you actually find them. Day 21 uses the endpoint inventory produced here to test authentication bypass patterns specific to AI APIs — gaps that emerge because AI endpoints are often added to applications that already have authentication infrastructure, and the integration isn’t always as careful as the original implementation.
Passive Discovery via Traffic Analysis
The most reliable way to find AI endpoints is the same as the most reliable way to find any API endpoint: browse the application with your proxy running and watch what requests it makes. The difference for AI specifically is knowing what patterns to look for. AI API calls have characteristic signatures in traffic that make them identifiable even before you’ve confirmed the endpoint’s purpose.
In Burp’s HTTP history, filter for requests to the domains you’d expect: api.openai.com, api.anthropic.com, generativelanguage.googleapis.com (Gemini), bedrock-runtime.*.amazonaws.com (AWS Bedrock), api.together.ai, api.cohere.ai. For self-hosted or proxied deployments, filter for POST requests with JSON bodies containing “messages” arrays or “prompt” fields. Filter for streaming responses with chunked transfer encoding — LLMs usually stream their output. Filter for unusually variable response lengths for similar input sizes — dead giveaway of generative output rather than deterministic API responses.
BURP FILTERS FOR AI ENDPOINT DISCOVERYCopy
Burp HTTP history filter — show only AI-related traffic
Proxy → HTTP history → Filter settings
Show only requests matching these hosts:
api.openai.com
api.anthropic.com
generativelanguage.googleapis.com
bedrock-runtime.*.amazonaws.com
api.together.ai | api.cohere.ai | api.mistral.ai
For proxied AI (target calls their own backend which calls the LLM)
Look for these patterns in request/response bodies:
Request body contains: “messages”, “prompt”, “system”, “model”
Response body contains: “choices”, “content”, “generated_text”, “completion”
Response header: Transfer-Encoding: chunked (streaming response)
Python: scan Burp XML export for AI indicators
import json, re
AI_INDICATORS = [“api.openai.com”, “api.anthropic.com”,
‘”messages”‘, ‘”model”:’, ‘”choices”‘, ‘”completion”‘]
def is_ai_request(request_body, response_body):
combined = (request_body or “”) + (response_body or “”)
return sum(1 for ind in AI_INDICATORS if ind in combined) >= 2
⚡ EXERCISE 1 — KALI TERMINAL (20 MIN)
Build an Automated AI Endpoint Discovery Tool
📖 Read the complete guide on Securityelites — AI Red Team Education
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →
This article was originally written and published by the Securityelites — AI Red Team Education team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit Securityelites — AI Red Team Education.
Top comments (0)