> For the complete documentation index, see [llms.txt](https://106-sam.gitbook.io/ejptv2-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://106-sam.gitbook.io/ejptv2-notes/crto/cobalt-strike/beacon-payloads/staged-vs-stageless-payloads.md).

# Staged vs Stageless payloads

It's common for attack frameworks, such as Metasploit and Cobalt Strike to decouple 'exploits' from 'payloads'. Imagine an application that has a code execution vulnerability due to a buffer overflow - the 'exploit' is the code that triggers the overflow and the 'paylaod' is the code you want executed as a result (e.g. Meterpreter or Beacon shellcode). The size of payload that you can deliver may be limited by factors such as the nature of the vulnerability itself, or the channel it's accessible on. If you're old like me, you may remember <br>

* **MS08-067** - an famous remote code execution (RCE) vulnerability in Windows. This was a stack corruption vulnerability which had to be exploited within a limit of \~400 bytes.

To combat these situations, 'payload staging' became popular. This consists of a small program (the stager) that when executed, reaches out to fetch the full payload (the stage) over a different channel from the exploit, such as HTTP, inject it into a new region of memory and pass execution to it. Payload staging is good for getting around these types of exploit restrictions, but they also have several drawbacks.