Simulacra: Vulnerability-Shaped Honeypots and the Blessed Relief of Not Owning Vulnerable…

The original intent of this project was not to create an app, a framework, a platform, or some other innovation-adjacent noun that can be placed reverently into a pitch deck beside a geometric logo.

I wanted to study TTPs.

That was it.

More specifically, I wanted to study how threat actors interact with specific vulnerabilities once they believe they have found a viable target. Not "post-exploitation activity" in the abstract. Not a bloodless diagram with arrows pointing from Initial Access to Impact as if human beings and their malformed shell scripts were ever so orderly. I wanted the real texture of the thing.

The commands they run. The assumptions they make. The callbacks they attempt. The payloads they stage. The directories they expect to exist. The little compulsive gestures that appear once someone believes the door has opened.

The obvious answer, of course, is a honeypot.

The less obvious problem is that realistic honeypots are profoundly annoying.

If I want to study exploitation against SharePoint, React/Next.js, Fortinet, WordPress, or whatever appliance has been selected by providence and bad patch management to ruin everyone's week, I cannot always just acquire the thing, deploy it, configure it into precisely the right vulnerable state, expose it to the internet, and then pretend that this is an efficient or especially sane research process.

Sometimes the product is expensive. Sometimes it is an appliance. Sometimes the vulnerable version is a museum piece. Sometimes the setup process feels like a penitential exercise. Sometimes the exploit chain depends on configuration conditions that are annoying to reproduce. Sometimes I do not want to expose a real vulnerable system to the internet because, despite appearances, I do retain some residual instinct for self-preservation.

So the question became less theatrical and more useful:

Can I simulate the experience of exploiting a vulnerable system without deploying the vulnerable system itself?

That is where AI became interesting.

Not because I wanted an LLM to "hack back." Not because I wanted to bolt a chatbot onto a honeypot and march triumphantly into the vaporous hellscape of AI thought leadership. Not because the world needs another MCP/no-code/API-wrapper contraption waddling around in a trench coat pretending to be a security product.

The useful part of AI, at least for this problem, is inference.

An LLM can look at messy input and infer what the user is trying to accomplish. In a normal application, that user might be asking a poorly phrased question. In this case, the "user" is some scanner, bot, operator, copy-paste enthusiast, or threat actor flinging exploit attempts, shell commands, serialized refuse, base64 effluvia, callback URLs, and other offerings into an endpoint.

The model does not need to execute the input.

It needs to understand the expected outcome.

Simulacra does not execute attacker commands. It does not deserialize hostile object graphs. It does not fetch attacker-hosted payloads indiscriminately. It does not write real web shells. It does not provide a working vulnerable system. It does not become the thing it is pretending to be, because that would be less "research platform" and more "incident report with extra architecture."

Simulacra's goal is simple:

• Preserve the input.
• Infer the intent
• Simulate the response.

The Basic Idea

Simulacra is a modular deception framework for vulnerability-shaped honeypots.

A traditional honeypot exposes a service and waits to be abused. It is, in many implementations, a receptacle for bad behavior. That is useful, but it is also somewhat passive. Simulacra attempts to go a step further. It creates the illusion that exploitation has succeeded while ensuring that the attacker never receives access to a real vulnerable system.

The point is not to emulate a full machine with perfect fidelity. That is a wonderful way to lose several months and emerge with a brittle artifact that fails the moment an attacker does something impolite, such as interact with it.

The point is to simulate enough of the externally observable experience to collect meaningful attacker behavior.

A React-shaped module should expose the endpoints, headers, routes, errors, and response patterns that make sense for the vulnerability being studied. A SharePoint-shaped module should look enough like the relevant SharePoint surface to attract ToolShell-style probing. A Fortinet-shaped module should have the flavor of the appliance without requiring me to keep a vulnerable appliance around racking up AWS rental fees

The module does not need to be the real product.

It needs to present the visible contour of the vulnerable product.

That is the distinction. Simulacra is not generating real vulnerabilities. It is simulating the observable conditions associated with vulnerable systems. The attacker sends what they believe is an exploitation attempt. Simulacra captures it, preserves it, interprets it, and returns a simulated response consistent with what the attacker likely expected.

The attacker receives the illusion of progress.

I receive evidence.

Why AI?

I am guilty of using AI to write code. I confess this with the appropriate level of shame and only a small amount of defensiveness.

But that is not the interesting part.

The interesting part is that AI can reduce the need to pre-structure every possible attacker input before it becomes useful.

Without AI, this sort of system quickly degenerates into an empire of parsers, regexes, conditional branches, brittle handlers, and increasingly desperate special cases. There are places where deterministic parsing is necessary and preferable. But attacker input is messy. Exploit traffic is messy. Payloads are malformed, encoded, double-encoded, truncated, copied incorrectly, mutated by scanners, passed through tools of dubious provenance, and frequently assembled by people who appear to be in open conflict with both syntax and God.

This is where inference is useful.

The AI Handler can examine the input and answer a practical question:

What did the attacker expect to happen?

If the attacker appears to be running whoami, Simulacra does not need to run whoami. It needs to return a plausible response. If the attacker attempts to write a file, Simulacra does not need to write that file into a real web root. It needs to preserve the attempted path, track the simulated state, and potentially reflect that state later in a controlled way.

If the attacker submits an exploit blob, Simulacra does not need to deserialize it, invoke it, or escort it into the runtime. It needs to preserve the artifact, identify the apparent objective, and respond as if the vulnerable surface behaved in the manner the attacker anticipated.

A believable deception environment cannot simply cough up static responses and hope nobody notices. Attackers often perform sequences of actions. They probe, test, write, retrieve, enumerate, stage, and validate. If the illusion has no memory, it collapses quickly. If the illusion becomes real, the entire exercise collapses morally, technically, and possibly legally.

So Simulacra sits in the deliberately narrow middle:

Infer enough to sustain the illusion. Preserve enough to support research. Constrain enough to remain safe.

What Simulacra Is

At present, Simulacra consists of three primary components:

1. the AI Handler,
2. the Vulnerability Module,
3. the Evidence Logger.

1. The AI Handler

The AI Handler is the interpretive layer between attacker input and simulated output.

The more theatrical version is to call it the "AI brain," but that phrase suggests a grandeur that is neither necessary nor deserved. The AI Handler is not a brain in the philosophical sense. It is not a sentient defender. It is not a SOC analyst trapped in a bottle. It is a constrained inference mechanism.

Its job is to receive attacker-provided input, infer intent, and generate a realistic simulated response based on the context of the active module.

In some modules, it behaves like a machine simulator. An attacker sends something command-like, and the handler returns what a vulnerable machine might plausibly return.

In other modules, it behaves more like an interpretation engine. This is useful when the exploit format is so variable that scripting every permutation would become a monument to resentment. Some payloads are structured. Some are semi-structured. Some are encoded some serialized.

The AI Handler uses module-specific personas. In standard AI language, these are system prompts. I prefer "persona" because the model is being asked to inhabit the constraints of a particular simulated target. A SharePoint module should not suddenly respond like an Ubuntu workstation unless the simulated state has a reason to make that plausible. A Fortinet-shaped module should restrict itself to a Fortinet existence.

Each persona constrains the model's role, expected environment, response style, and safety limits.

The current implementation uses AWS Bedrock. This is not because Bedrock is uniquely ordained. It is mostly because it provides access to capable models at a price point and integration path that does not bankrupt me. There is no strong LLM commitment here. Future implementations could support Ollama, Claude, OpenAI, or other model providers.

2. The Vulnerability Module

The Vulnerability Module is what gives Simulacra its shape.

At the moment, these are FastAPI modules customized to handle the web requests associated with a specific vulnerability, product, or exploit surface. The module defines the routes, headers, status codes, response bodies, fake files, skeletal directory structures, and behavioral peculiarities needed to make the target plausible.

This is where the deception becomes concrete.

A module should not merely expose a single endpoint and call the matter settled. That kind of laziness may pass in a slide deck, but scanners and attackers often look for surrounding context. They check headers. They probe common paths. They request static files. They look for login pages, API routes, version artifacts, error messages, and other incidental residue that suggests the service is what it claims to be.

A WordPress-shaped target should have WordPress-like surroundings. A SharePoint-shaped target should smell vaguely of SharePoint. A React-shaped target should expose the expected application contours.

This does not mean implementing the real application.

It means implementing the expected surface.

The module presents the visible conditions necessary for the vulnerability being studied. It also maintains simulated state where that state matters. If an attacker attempts to drop a file, create a path, configure a callback, stage a payload, or retrieve something they believe they wrote, the module can preserve that attempted state and refer to it later.

The module hooks into the AI Handler when interpretation or simulated output is useful. Not every response requires AI. Some responses should be deterministic. Some conditions should be scripted. Some artifacts should be static. Where the form of the vulnerability module is static it is scripted. Where it needs to be scripted it is scripted, where it needs to be dynamic it is inferred.

AI is used where inference adds value.

3. The Evidence Logger

The Evidence Logger is at the core of how results are studied and published.

Every interaction needs to be preserved. Raw requests matter. Headers matter. Paths matter. Payloads matter. Timing matters. Source metadata matters. The inferred intent matters too, but only when it is attached to the underlying evidence rather than allowed to replace it.

AI models can be wrong. It is important that the attacker input is the artifact.

That principle matters because AI summaries have an unfortunate habit of sounding confident even when they are quietly hallucinating. The logger therefore needs to preserve both the original interaction and the interpretation generated from it.

At minimum, I want to capture:

• timestamp,
• source IP and request metadata,
• active module,
• requested endpoint,
• headers,
• raw body,
• decoded or extracted payloads where safe,
• simulated state changes,
• AI interpretation,
• simulated response,
• confidence or uncertainty,
• referenced URLs or file paths,
• hashes and metadata for any safely collected payloads.

The purpose is to build a knowledge base of exploitation attempts, tooling patterns, assumptions, payload staging behavior, and post-exploitation intent.

That is where Simulacra becomes useful as a research instrument.

I do not only want to know that someone knocked on the door.

I want to know what they tried to do after they believed the door opened.

What This Is Not

Simulacra is not an exploit framework.

It is not a system for running attacker commands. It is not a malware detonation chamber. It is not a vulnerable appliance cosplay environment that accidentally becomes the real thing. It is not a place to deserialize hostile payloads in the name of "understanding them," which is how one ends up starring in a cautionary tale.

It is a deception and evidence collection framework.

The purpose is to make the attacker believe they are interacting with a vulnerable system while ensuring they are not.

Why This Matters

A great deal of vulnerability research focuses, understandably, on whether exploitation is possible. That matters. But once a vulnerability becomes public, I am often just as interested in the secondary question:

What do attackers actually do with it?

Do they test for command execution? Do they enumerate the environment? Do they assume Linux? Windows? Containers? Cloud metadata? Do they attempt credential theft? Do they stage second payloads? Do they drop web shells? Do they reuse infrastructure? Do they reveal tooling? Do they make mistakes? Do they show recognizable tradecraft? Do they behave like an operator, a bot, a scanner, or a simple an angry individual.

Those questions are difficult to answer from theory alone.

They require interaction.

But interaction with real vulnerable systems is slow, expensive, and risky. Simulacra is my attempt to build a safer intermediary: believable enough to elicit meaningful attacker behavior, constrained enough to avoid becoming the vulnerable system it imitates.

That is the part I am proud of.

I did not set out to build a framework. I set out to study threat actor behavior. The framework accreted around the research problem because the research problem kept demanding something reusable, modular, and fast enough to respond to new vulnerabilities while they are still active.

There is a difference between chasing novelty and discovering utility.

This feels like the latter.

Not because it is AI. Not because it has a name. Not because I have any desire to contribute another "AI-powered cybersecurity platform" to the great landfill of vendor adjectives.

Because it solves a real research problem:

How do I rapidly deploy believable vulnerability-shaped environments, collect exploitation attempts, and turn those attempts into knowledge about attacker behavior without deploying real vulnerable infrastructure?

That is the use case.

Next Steps

There are several pieces I still want to build.

Cloud Evidence Writer

Right now, evidence can be written locally, but local evidence is not sufficient for the kind of longitudinal analysis I want to do. The logs are structured, but they need to land somewhere more useful: object storage, a database, a SIEM, or some other system that allows for correlation, trend analysis, and longer-term study.

I want to see patterns over time. I want to know whether particular vulnerabilities attract certain payloads, whether specific exploit attempts cluster around infrastructure, whether post-exploitation behavior changes as public tooling matures, and whether different modules produce meaningfully different attacker behavior.

Safe Payload Collector

Commands are only part of the story. Many exploitation attempts reference second-stage payloads, shell scripts, malware, or external infrastructure.

I want a controlled payload collector that can retrieve referenced artifacts into isolated storage for hashing and analysis. The collector must be aggressively boring: no execution, no callbacks, no helpful interpretation through detonation, no "let's see what happens," no heroic nonsense.

Retrieve the artifact. Preserve the context. Hash it. Store it safely. Treat it as hostile evidence.

That is all.

Malware does not need encouragement.

AWS Deployment Examples

I plan to deploy Simulacra in AWS and document safe deployment patterns. This may involve a VM, a container, Lambda, or some combination depending on the needs of the module.

The deployment model needs to be boring in the right ways: isolated, observable, constrained, disposable, and incapable of becoming someone else's problem.

The last thing that needs to happen is that the deception environment become a staging server, malware host, open relay, pivot point, or future apology email.

The goal is to document deployment patterns that are safe, ethical, and actually usable.

Module Authoring Interface

The long-term value of Simulacra depends on how quickly new modules can be created.

I want module authoring to be simple enough that a researcher can define the surface of a target, add the relevant routes and response conditions, attach an appropriate AI persona, and iterate without turning the process into a second unpaid job.

The ideal module authoring process should answer a few practical questions:

What does the vulnerable product look like from the outside? What endpoints matter? What headers, errors, files, and status codes are expected? What exploit condition is being simulated? What state needs to persist? Where should deterministic logic end and AI inference begin?

The goal is rapid reaction.

When a new vulnerability appears, I do not want to spend days constructing a fragile theatrical set while attackers are already moving on to the next thing. I want to define enough of the vulnerable surface to attract relevant behavior, deploy it safely, and start collecting evidence.

Closing

Simulacra came out of a simple research need: I wanted to study threat actor behavior tied to specific vulnerabilities without constantly deploying real vulnerable systems.

AI made that practical because it can infer intent from messy attacker input and generate believable simulated responses. The modular design made it reusable. The evidence model made it useful.

That is the heart of it.

Simulacra is a vulnerability-shaped honeypot framework that uses AI inference to create the illusion of exploitation while preserving the evidence of what attackers attempted to do.

It is a controlled deception environment for studying attacker behavior.

The repo can be found on GitHub here: https://github.com/dacman28/simulacra

And, against my better instincts, I am quite proud of it.