Andromeda: One Researcher's Agentic AI Payload Framework
Carl Vincent, a Straiker researcher, built Andromeda: an AI agent that writes its own red team payloads in real time. A Toorcamp 2026 prototype, now open source.
Why Straiker's newest red-team side project is named after a 1969 sci-fi novel, not a decade-old botnet. The name is a nod to Michael Crichton's 1969 novel The Andromeda Strain. It predates, and has no connection to, the Andromeda/Gamarue botnet taken down in 2017. Straiker employs a number of AI security researchers to facilitate its mission of securing the global agentic ecosystem. These individuals are highly motivated experts with a passion for not just agentic security, but information security in general. As such, in order to maintain a healthy and psychologically stimulating environment for innovation, Straiker encourages the occasional endeavor into side projects that push the boundaries of agentic engineering and agentic security tradecraft. This past week, one such researcher presented some of their creative “side work” at Toorcamp, a biennial “American hacker camp” that provides an environment where creative individuals can showcase projects and connect with other technology experts. This writing is an expression of that content tailored for Straiker’s audience.
What happened: Straiker researcher Carl Vincent built and demoed Andromeda, a prototype framework that uses 2 LLM agents to generate position-independent bytecode payloads on the fly, tailored to a target's exact memory context at the moment of execution, instead of relying on pre-built, static post-exploitation tools.
Why it matters: Most detection today looks for known payload signatures or file-based artifacts. A payload an agent writes fresh for each target, in memory, based on live context, doesn't leave those artifacts behind. That's a preview of how agentic AI changes offensive tradecraft, and it's a preview defenders need to see now, not after it shows up in the wild.
So what: This is a research prototype, not a packaged exploit. But the underlying pattern, an agent reasoning about a live memory context and building code to fit it, is a capability class security teams should start tracking, the same way they track any new class of evasion technique.
The Backstory: Why Offensive Operators Avoid Reverse Shells
As someone whose early - mid career consists almost entirely of conducting offensive security operations of one form or another, I’ve developed a bit of a compulsion with developing implant / command and control (C2) frameworks. As I’ve moved to focus more of my research on AI, I’ve become fascinated with the various methodologies of combining traditional C2 ecosystems with agentic capabilities. With this motivation in mind, I'll provide a brief overview of why offensive operators tend to prefer in-memory executed “payloads” vs direct interaction through methods like reverse-shells.
In-memory payloads are preferred in offensive tradecraft because they execute entirely in RAM without writing files to disk, evading file-based antivirus, EDR detection, and forensic artifacts. Unlike reverse shells, which create “noisy”, monitorable network connections and persistent processes that are easier to detect and attribute. In general, in-memory execution is considered stealthier, more ephemeral, and often bypasses behavioral controls focused on disk activity and outbound shells, even when deterrents such as anti-virus or endpoint detection (EDR / XDR) systems are in place.
Anyone who is familiar with the history of offensive security tradecraft is going to be familiar with the Metasploit (MSF) framework. And subsequently, anyone familiar with MSF is going to be familiar with Meterpreter. The purpose of Meterpreter is to serve as the kind of “generic payload” for post-exploitation tasks, providing a more predictable memory environment upon which to execute subsequent payloads designed to perform specific tasks (such as taking screen shots or performing pivoting operations like instantiating dual-honed network proxies). While Meterpreter helps, the memory environments of computational systems are constantly shifting. This influences payload execution downstream from Meterpreter to be somewhat brittle, as well as requiring regular maintenance from the open source community to maintain on the plethora of platforms supported by MSF.
In order to combat this, in 2010, Patrick HVE, Stephen Fewer, Chao-mu, Ben Cambell, OJ Reeves, and others within the MSF developer community released Railgun, a post exploitation feature exclusive to Microsoft Windows that exposed a ruby terminal interface to the native Windows API. Later popularized by offensive operators such as Mubix and Egypt, this sub-system allowed MSF operators to interact directly with the Windows API by performing realtime hooking of the native operating system (OS) function pool. This meant that operators could call native OS functionality without doing pointer math in order to trigger actions within targets and removed the requirement of in-memory execution for post-exploitation activities being standardized for all memory environments prior to deployment.
It is on this idea that Andromeda builds, the premise being “if i can hook native OS functionality using only an understanding of what a function does, and its relative offset to my present memory context, why do i need a terminal at all? Might I be able to leverage said functionality agentically, thus removing the requirement of an interactive “shell” entirely?
Turns out the answer is “Yes”, and the “how” is what the rest of this article is about :).
How Andromeda Turns Native OS Functions Into Agentic Capabilities
Yes, there are spelling mistakes in this diagram, but it's the one presented by the code repository at the time of this writing and it's the one I used in my slides so I'm keeping it as is for consistency :)
Andromeda combines three local components into one agentic workflow for generating, transporting, visualizing, and executing position independent bytecode specifically compiled for the memory context instantiated at runtime by its associated implant through a live runtime context. The 3 systems work in tandem to identify the context of memory at runtime within a target, transmit that context to an agent, and then subsequently build payloads for that exact contact in near real time before transmitting them to individual targets for execution. The 3 components are identified by the table below
Web app, graph database, WebSocket broker, Tinkr orchestration service, and agentic chat surface. It receives Tailor check-ins and dispatches generated bytecode jobs.
The way the workflow Andromeda executes is relatively strait forward and can be thought of as a series of execution steps
- First, the operator starts the command and control container. This is the “hub” for all interactive activity and houses an HTTP distribution point as well as an “admin” agentic interface and the payload builder known as Tinkr.
- Once the interface is started, the operator performs whatever offensive security tasks are required to instantiate Tailor. Tailor is the “implant” of the C2 / implant framework, upon instantiation, it enumerates as many of the native OS functions as it can and notes their offset relative to its process. It subsequently transmits this information to Soldir (the C2) via an HTTP request and then continuously reads from a websocket instantiated upon successful connection for bytecode payloads to subsequently execute.
- Once the “checkin” process between Tailor and Soldir has been completed and the websocket communication pathway has been established, the operator may use the admin UI within Soldir to agenticly issue commands to targets under it’s preview. When the agent within Soldir receives these instructions it interfaces with Tinkr.
- Tinkr is a payload builder, it receives instructions from the agent within Soldir, and then subsequently uses those instructions to leverage an agentic interface to write LLVM-IR. This agentic interface is pre-populated with SKILL.md files derived from publicly available native function documentation for a variety of of OS platforms. The context within the SKILLs and the LLVM-IR agentic interface combination facilitates Tinkr to “understand” what each OS function does while also knowing ‘where it is’ in relation to the implant’s memory context. This facilitates its purpose, which is constructing position independent bytecode payloads that perform the tasks requested by the operator via Soldir before they are subsequently transmitted via websocket to intended targets.
Is Andromeda Production-Ready?
At present, Andromeda is very much a “prototype”, there is a LOT of trial testing and operational “smoothing” that needs to be done in order to ensure the operational flow of operator -> admin interface -> Tinkr -> execution within tailor is “well paved” and stable. I also haven’t done any real testing on platforms beyond MacOS and emulated Windows targets, and I’ve yet to experiment with payloads that return things to the operator (now that I’m writing this, I didn’t build in any standard method of storing “loot”, PRs accepted!). Beyond operational stability the SKILLs database currently implemented within Tinkr is “enough to get started” but it's far from “pedantic”. For anyone with a significant pool of “tokens”, the process of adding functions is really quite simple, as the vast majority of memory level API functions are already publicly documented, as well as being written in such a manner that yields itself to being organized in an AI SKILL format. (this is a really easy thing to vibe up and contributions from the infosec community could really help here, just sayin :)).
Ugh, yet another implant / C2 framework. Why did you even build this?
Among all of the ostensible horror that Large Language Models (LLMs) and AI in general is poised to thrust upon humanity, there are also objectively beautiful benefits, (some speculative, some already realized). I firmly believe that there is a future where the concept of “code” as an abstraction ceases to exist, and instead the very nature of “computational functionality” (inclusive of “object oriented” abstraction) is replaced by agentic interfaces to realtime native bytecode instructions. An analogous example of this might be described by the character Jordy on the Star Trek series “The Next Generation”. Jordy (the chief engineer) does not program or “code”, to solve problems, he walks up to a terminal, taps a button to engage an “agentic” interface, and he literally speaks to the “main computer”, prompting it to do everything from advanced engineering simulations based on realtime conditions to “tool” based kinetic analysis on physical entities too abstract or tangibly unwieldy for humans to manipulate (i.e. telling the “main deflector” to do something with “tacheons”). I firmly believe that within the very near future, this could be reality for the way that humanity engages with the entirety of the consumer electronics ecosystem. I’m not sure if this tiny (if “problematic”) contribution to that mission will help get us there, but it's “the thing I know how to do” so I hope it has that effect :).
Using Andromeda to Test Payloads Safely Before Live Deployment
A benefit of this framework that I didn’t even think of until testing it is the potential for “operational stability” beyond the execution of target bespoke code. As an experienced offensive operator, the VAST majority of my carrier has been spent tackling the task of “um, I want to do $thing on $target and I THINK this payload contraption will work, but im not sure and I don’t want to blow up my access context in the process, how do I test this?”. I’ve never really come up with a universal approach to solving this problem but Andromeda actually might! The benefit of Soldir being full blown agentic software is that there is nothing stopping downstream developers from expanding the agentic harness into a full blown local operational agent like Codex or Claude CLI; The important factor being that it theoretically exposes the work flow of “Hay Andromida, I want to do X on target Y but I don’t know if it will work, go build a replica in <Docker / A VM via Kubernetes / etc>, instantiate Tailor within it, and practice running a payload that does $ABC against it until it works, THEN go run it on Y”; Which is something I absolutely would have wanted during my offense days :)
About the researcher
Carl Vincent (vyrus) is an AI security researcher at Straiker with decades of experience spanning offensive security, fraud and threat intelligence, and adversary engagement. He's helped Fortune 10 companies, fintechs, and AI firms build resilient security programs, and is known in the community for translating complex threat models into actionable strategies for both red and blue teams.
Carl's work reflects the kind of independent tradecraft Straiker wants its researchers pursuing: public, hands-on, and unafraid of the harder edges of AI security. More research: straiker.ai/research.
FAQs
Is "Andromeda" related to the 2011 Andromeda/Gamarue botnet?
No. This project is named after Michael Crichton's 1969 novel The Andromeda Strain, chosen before this post was written; the name was already attached to Carl's Toorcamp talk and the public GitHub repo. Renaming now would break continuity with both.
Is Andromeda a working tool or a proof of concept?
Prototype. It runs and demonstrates the full workflow, but Carl is upfront that operational stability, cross-platform testing, and the SKILL.md function library all need more work before this is production-grade tradecraft.
Where can someone get the code or contribute?
https://github.com/vyrus001/andromeda — Carl's explicitly asking for community contributions, particularly around expanding the native-function documentation.
Why Straiker's newest red-team side project is named after a 1969 sci-fi novel, not a decade-old botnet. The name is a nod to Michael Crichton's 1969 novel The Andromeda Strain. It predates, and has no connection to, the Andromeda/Gamarue botnet taken down in 2017. Straiker employs a number of AI security researchers to facilitate its mission of securing the global agentic ecosystem. These individuals are highly motivated experts with a passion for not just agentic security, but information security in general. As such, in order to maintain a healthy and psychologically stimulating environment for innovation, Straiker encourages the occasional endeavor into side projects that push the boundaries of agentic engineering and agentic security tradecraft. This past week, one such researcher presented some of their creative “side work” at Toorcamp, a biennial “American hacker camp” that provides an environment where creative individuals can showcase projects and connect with other technology experts. This writing is an expression of that content tailored for Straiker’s audience.
What happened: Straiker researcher Carl Vincent built and demoed Andromeda, a prototype framework that uses 2 LLM agents to generate position-independent bytecode payloads on the fly, tailored to a target's exact memory context at the moment of execution, instead of relying on pre-built, static post-exploitation tools.
Why it matters: Most detection today looks for known payload signatures or file-based artifacts. A payload an agent writes fresh for each target, in memory, based on live context, doesn't leave those artifacts behind. That's a preview of how agentic AI changes offensive tradecraft, and it's a preview defenders need to see now, not after it shows up in the wild.
So what: This is a research prototype, not a packaged exploit. But the underlying pattern, an agent reasoning about a live memory context and building code to fit it, is a capability class security teams should start tracking, the same way they track any new class of evasion technique.
The Backstory: Why Offensive Operators Avoid Reverse Shells
As someone whose early - mid career consists almost entirely of conducting offensive security operations of one form or another, I’ve developed a bit of a compulsion with developing implant / command and control (C2) frameworks. As I’ve moved to focus more of my research on AI, I’ve become fascinated with the various methodologies of combining traditional C2 ecosystems with agentic capabilities. With this motivation in mind, I'll provide a brief overview of why offensive operators tend to prefer in-memory executed “payloads” vs direct interaction through methods like reverse-shells.
In-memory payloads are preferred in offensive tradecraft because they execute entirely in RAM without writing files to disk, evading file-based antivirus, EDR detection, and forensic artifacts. Unlike reverse shells, which create “noisy”, monitorable network connections and persistent processes that are easier to detect and attribute. In general, in-memory execution is considered stealthier, more ephemeral, and often bypasses behavioral controls focused on disk activity and outbound shells, even when deterrents such as anti-virus or endpoint detection (EDR / XDR) systems are in place.
Anyone who is familiar with the history of offensive security tradecraft is going to be familiar with the Metasploit (MSF) framework. And subsequently, anyone familiar with MSF is going to be familiar with Meterpreter. The purpose of Meterpreter is to serve as the kind of “generic payload” for post-exploitation tasks, providing a more predictable memory environment upon which to execute subsequent payloads designed to perform specific tasks (such as taking screen shots or performing pivoting operations like instantiating dual-honed network proxies). While Meterpreter helps, the memory environments of computational systems are constantly shifting. This influences payload execution downstream from Meterpreter to be somewhat brittle, as well as requiring regular maintenance from the open source community to maintain on the plethora of platforms supported by MSF.
In order to combat this, in 2010, Patrick HVE, Stephen Fewer, Chao-mu, Ben Cambell, OJ Reeves, and others within the MSF developer community released Railgun, a post exploitation feature exclusive to Microsoft Windows that exposed a ruby terminal interface to the native Windows API. Later popularized by offensive operators such as Mubix and Egypt, this sub-system allowed MSF operators to interact directly with the Windows API by performing realtime hooking of the native operating system (OS) function pool. This meant that operators could call native OS functionality without doing pointer math in order to trigger actions within targets and removed the requirement of in-memory execution for post-exploitation activities being standardized for all memory environments prior to deployment.
It is on this idea that Andromeda builds, the premise being “if i can hook native OS functionality using only an understanding of what a function does, and its relative offset to my present memory context, why do i need a terminal at all? Might I be able to leverage said functionality agentically, thus removing the requirement of an interactive “shell” entirely?
Turns out the answer is “Yes”, and the “how” is what the rest of this article is about :).
How Andromeda Turns Native OS Functions Into Agentic Capabilities
Yes, there are spelling mistakes in this diagram, but it's the one presented by the code repository at the time of this writing and it's the one I used in my slides so I'm keeping it as is for consistency :)
Andromeda combines three local components into one agentic workflow for generating, transporting, visualizing, and executing position independent bytecode specifically compiled for the memory context instantiated at runtime by its associated implant through a live runtime context. The 3 systems work in tandem to identify the context of memory at runtime within a target, transmit that context to an agent, and then subsequently build payloads for that exact contact in near real time before transmitting them to individual targets for execution. The 3 components are identified by the table below
Web app, graph database, WebSocket broker, Tinkr orchestration service, and agentic chat surface. It receives Tailor check-ins and dispatches generated bytecode jobs.
The way the workflow Andromeda executes is relatively strait forward and can be thought of as a series of execution steps
- First, the operator starts the command and control container. This is the “hub” for all interactive activity and houses an HTTP distribution point as well as an “admin” agentic interface and the payload builder known as Tinkr.
- Once the interface is started, the operator performs whatever offensive security tasks are required to instantiate Tailor. Tailor is the “implant” of the C2 / implant framework, upon instantiation, it enumerates as many of the native OS functions as it can and notes their offset relative to its process. It subsequently transmits this information to Soldir (the C2) via an HTTP request and then continuously reads from a websocket instantiated upon successful connection for bytecode payloads to subsequently execute.
- Once the “checkin” process between Tailor and Soldir has been completed and the websocket communication pathway has been established, the operator may use the admin UI within Soldir to agenticly issue commands to targets under it’s preview. When the agent within Soldir receives these instructions it interfaces with Tinkr.
- Tinkr is a payload builder, it receives instructions from the agent within Soldir, and then subsequently uses those instructions to leverage an agentic interface to write LLVM-IR. This agentic interface is pre-populated with SKILL.md files derived from publicly available native function documentation for a variety of of OS platforms. The context within the SKILLs and the LLVM-IR agentic interface combination facilitates Tinkr to “understand” what each OS function does while also knowing ‘where it is’ in relation to the implant’s memory context. This facilitates its purpose, which is constructing position independent bytecode payloads that perform the tasks requested by the operator via Soldir before they are subsequently transmitted via websocket to intended targets.
Is Andromeda Production-Ready?
At present, Andromeda is very much a “prototype”, there is a LOT of trial testing and operational “smoothing” that needs to be done in order to ensure the operational flow of operator -> admin interface -> Tinkr -> execution within tailor is “well paved” and stable. I also haven’t done any real testing on platforms beyond MacOS and emulated Windows targets, and I’ve yet to experiment with payloads that return things to the operator (now that I’m writing this, I didn’t build in any standard method of storing “loot”, PRs accepted!). Beyond operational stability the SKILLs database currently implemented within Tinkr is “enough to get started” but it's far from “pedantic”. For anyone with a significant pool of “tokens”, the process of adding functions is really quite simple, as the vast majority of memory level API functions are already publicly documented, as well as being written in such a manner that yields itself to being organized in an AI SKILL format. (this is a really easy thing to vibe up and contributions from the infosec community could really help here, just sayin :)).
Ugh, yet another implant / C2 framework. Why did you even build this?
Among all of the ostensible horror that Large Language Models (LLMs) and AI in general is poised to thrust upon humanity, there are also objectively beautiful benefits, (some speculative, some already realized). I firmly believe that there is a future where the concept of “code” as an abstraction ceases to exist, and instead the very nature of “computational functionality” (inclusive of “object oriented” abstraction) is replaced by agentic interfaces to realtime native bytecode instructions. An analogous example of this might be described by the character Jordy on the Star Trek series “The Next Generation”. Jordy (the chief engineer) does not program or “code”, to solve problems, he walks up to a terminal, taps a button to engage an “agentic” interface, and he literally speaks to the “main computer”, prompting it to do everything from advanced engineering simulations based on realtime conditions to “tool” based kinetic analysis on physical entities too abstract or tangibly unwieldy for humans to manipulate (i.e. telling the “main deflector” to do something with “tacheons”). I firmly believe that within the very near future, this could be reality for the way that humanity engages with the entirety of the consumer electronics ecosystem. I’m not sure if this tiny (if “problematic”) contribution to that mission will help get us there, but it's “the thing I know how to do” so I hope it has that effect :).
Using Andromeda to Test Payloads Safely Before Live Deployment
A benefit of this framework that I didn’t even think of until testing it is the potential for “operational stability” beyond the execution of target bespoke code. As an experienced offensive operator, the VAST majority of my carrier has been spent tackling the task of “um, I want to do $thing on $target and I THINK this payload contraption will work, but im not sure and I don’t want to blow up my access context in the process, how do I test this?”. I’ve never really come up with a universal approach to solving this problem but Andromeda actually might! The benefit of Soldir being full blown agentic software is that there is nothing stopping downstream developers from expanding the agentic harness into a full blown local operational agent like Codex or Claude CLI; The important factor being that it theoretically exposes the work flow of “Hay Andromida, I want to do X on target Y but I don’t know if it will work, go build a replica in <Docker / A VM via Kubernetes / etc>, instantiate Tailor within it, and practice running a payload that does $ABC against it until it works, THEN go run it on Y”; Which is something I absolutely would have wanted during my offense days :)
About the researcher
Carl Vincent (vyrus) is an AI security researcher at Straiker with decades of experience spanning offensive security, fraud and threat intelligence, and adversary engagement. He's helped Fortune 10 companies, fintechs, and AI firms build resilient security programs, and is known in the community for translating complex threat models into actionable strategies for both red and blue teams.
Carl's work reflects the kind of independent tradecraft Straiker wants its researchers pursuing: public, hands-on, and unafraid of the harder edges of AI security. More research: straiker.ai/research.
FAQs
Is "Andromeda" related to the 2011 Andromeda/Gamarue botnet?
No. This project is named after Michael Crichton's 1969 novel The Andromeda Strain, chosen before this post was written; the name was already attached to Carl's Toorcamp talk and the public GitHub repo. Renaming now would break continuity with both.
Is Andromeda a working tool or a proof of concept?
Prototype. It runs and demonstrates the full workflow, but Carl is upfront that operational stability, cross-platform testing, and the SKILL.md function library all need more work before this is production-grade tradecraft.
Where can someone get the code or contribute?
https://github.com/vyrus001/andromeda — Carl's explicitly asking for community contributions, particularly around expanding the native-function documentation.
