CodeX's Terminal Window
  • root@codex
  • 🐙Red Team
    • Red Team OPSEC
      • Initial Recon
      • Weaponization
      • Infrastructure
        • Example Red Team Infra
        • Cobalt Strike Redirectors
        • Using SSH Tunneling to secure C2 infra
      • Phishing
      • Internal Recon
      • Lateral Movement
      • Post-Exploitation
      • Exfiltration
      • Cleanup
    • Red Team TTPs
      • Active Directory
      • Persistence
      • Exfiltration
      • Phishing
      • Windows Bypasses
    • Red Team Dev
      • Extending Havoc C2
        • Third Party Agents
          • 1: Understanding the interface
          • 2: Writing the agent
          • 3: Writing the agent handler
          • 4: Testing the agent
      • Loader Dev
        • In Memory OPSEC
          • PE Structures
          • Memory Permissions and Allocation Types
          • In Memory Signatures
          • Thread Stack
          • Windows Events
          • Userland Hooks
          • AMSI & ETW
        • Evasion Adventures
        • Loader basics
        • Sleep masking
        • Mimikatz vs Windows Defender
        • Indirect syscalls
    • Cobalt Strike
      • Modifying the Sleep Mask Kit
      • Discord Beacon Notifications
      • Evading Hunt-Sleeping-Beacons
      • Beacon Object Files
    • Misc. Interesting Stuff
  • 🛡️Blue Team
    • Detecting Cobalt Strike
      • Sleep Mask Kit IOCs
      • Hunting Beacon in the heap
      • Decrypting C2 traffic with known key
  • 🚩CTF Solutions
    • Cyber Defenders Discovery Camp 2021
      • 👁️‍🗨️Lets Go Hunting
      • 🐧Linux Rules The World!
      • 📻Going active
      • 🗄️File it away
      • 😷Behind the mask
  • Box challenges
    • 📦Box Writeups
  • Me myself and I
    • root@codex #
Powered by GitBook
On this page
  • Callback specifications
  • The third party agent system
  1. Red Team
  2. Red Team Dev
  3. Extending Havoc C2
  4. Third Party Agents

1: Understanding the interface

PreviousThird Party AgentsNext2: Writing the agent

Last updated 2 years ago

Before writing the agent and its handler, we need to understand how Havoc handles third party agents.

Callback specifications

Since we are handling our own custom agent's callbacks ourselves, there isn't a fixed callback data structure we have to follow. However, there is a fixed set of bytes that must be prepended to each callback that gives Havoc some basic information on how to handle the callback. These bytes are as such:

[4 bytes] size - this is the total size (in bytes) of the request (including the 12 byte header)
[4 bytes] magic value - this is the value that is used to identify the custom agent type. It has to be common between all agents of the same type.
[4 bytes] agent ID - this is a 4 byte agent ID. This can be any value, but it should be unique per agent, so randomly generating it during runtime is a good idea.

So the structure of a typical callback should be something like this:

The third party agent system

The way Havoc third party agents work, is that any data sent to a valid C2 listening interface (http/s, external c2 etc.) is checked for its magic value, and forwarded to the appropriate agent handler. For example:

That's pretty much all you need to understand about Havoc's third party agent interface.

🐙
Callback structure
Havoc third party agent system