Using Large Language Models for Reconnaissance

Workflow: real tools gather facts, the model organises and explains, you verify each lead.

Reconnaissance is the least glamorous part of an engagement and often the most decisive. It is also the phase where language models earn their keep most honestly, because so much of it is reading, correlating and summarising, and those are exactly the things a model does quickly. Used with discipline, an LLM turns days of open-source intelligence work into hours. Used carelessly, it produces a confident, tidy report full of things that are not true.

What It Speeds Up

The gains are in volume and synthesis. A model will read a company’s entire public web presence, its job adverts, its engineering blog, its conference talks and its people’s public profiles, and pull out the technical detail that matters: the frameworks they hire for, the cloud they run on, the tools their engineers mention, the naming conventions they use. Scattered across fifty pages, this takes a human a long afternoon. A model gathers it in one pass and writes it up.

It is equally good at the tedious transforms: turning a messy list of subdomains into a structured inventory, explaining what an unfamiliar technology in the stack does, drafting the wordlists and permutations you will feed to other tools, and translating findings into the language a client’s board will understand.

The Trap: Confident Invention

A model asked for facts it does not have will supply them anyway. Ask it for a company’s subdomains and it will produce a plausible list, some of which never existed. Ask it for the CVEs affecting a piece of software and it will cite identifiers in the right format that were never issued. Ask it for an employee’s email pattern and it will guess and present the guess as fact.

In reconnaissance this is corrosive, because recon feeds every later phase. A fabricated subdomain wastes scanning time. A hallucinated CVE sends you down an exploit path that does not exist. The rule is simple and absolute: a model may organise and explain information, but the information itself must come from a tool that actually queried the world. Never let the model be the source of a fact. Let it be the thing that makes real facts legible.

A Workflow That Holds Up

The pattern that works keeps the model out of the fact-finding and inside the analysis. Real tools do the gathering: certificate transparency logs, DNS enumeration, port scans, the actual pages of the actual site. Their raw output, which is true because it was measured, is what you hand the model. Then you ask it to structure, prioritise and explain that output, and to suggest where to look next. Every suggestion it makes is then checked with a tool before it becomes a fact in your notes.

Kept in that lane, the model is a research assistant that never gets tired and reads faster than you do. Allowed out of it, into generating the underlying data, it quietly poisons the engagement.

The Other Side of the Coin

The same capabilities are available to attackers, at scale and without scruple. The mass personalisation of phishing, the rapid profiling of targets, the automated correlation of leaked data: all of it is cheaper now. For defenders, the lesson is that the reconnaissance an attacker can do against your organisation has become faster and broader, so the public information you leak matters more than it did, not less. What your job adverts reveal about your stack is now read by a machine in seconds.

The Short Version

Language models make reconnaissance faster by reading and synthesising public information at a speed no human matches. The danger is that a model will invent facts as readily as it reports them, and recon feeds everything downstream. Keep the model to organising and explaining data that real tools gathered, never let it be the source of a fact, and remember that attackers now have the same speed pointed at you.