{
	"id": "43043664-7d59-410f-9366-787841fd1a07",
	"created_at": "2026-04-06T00:08:12.236678Z",
	"updated_at": "2026-04-10T13:11:39.069098Z",
	"deleted_at": null,
	"sha1_hash": "e47537269473e68bd0849c42fa5d5d7c142a687d",
	"title": "Havoc C2 Framework – A Defensive Operator’s Guide",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4419589,
	"plain_text": "Havoc C2 Framework – A Defensive Operator’s Guide\r\nBy Immersive\r\nPublished: 2024-04-09 · Archived: 2026-04-05 22:59:47 UTC\r\nContributors\r\nThe Havoc command and control (C2) framework is a flexible post-exploitation framework written in Golang,\r\nC++, and Qt, created by C5pider. Engineered to support red team engagements and adversary emulation, Havoc\r\noffers a robust set of capabilities tailored for offensive security operations.Havoc was first released in October\r\n2022, and is still under active development. At the time of writing, Havoc supports HTTP(s) and SMB as a\r\ncommunication protocol for the implants. Havoc’s ability to generate payloads, including exe binaries, dll files,\r\nand shellcode, appeals to threat actors seeking a malleable and simple post-exploitation framework for their\r\ncampaigns.This research aims to empower defenders to detect the presence of Havoc, analyze its proprietary\r\nagents, known as Demons, and enhance organizational resilience against modern post-exploitation attack flows.\r\nHavoc is open-source, simple to use, and has little defensive-focused coverage, making it a popular option for\r\nadversaries. Over time, it’s likely to grow even more popular, particularly as other tools like Cobalt Strike already\r\nhave extensive defensive coverage. Some organizations like ZScaler, Critical Start, and The Stack have analyzed\r\nHavoc demons actively used in the wild targeting government organizations.Between Q4 2022 and Q1 2023,\r\nHavoc coverage increased as it could be used to bypass the latest version of Windows 11 Defender. Threat actors\r\nhave since utilized Havoc, leveraging third-party tools and plugins to bypass AV and EDR solutions, enhancing\r\ntheir flexibility in attacks. Between Q2 and Q4 2023, Spamhaus released its Botnet Threat Updates report,\r\nrevealing a 22% increase in the use of Havoc as a backdoor during that period. The graph below represents the\r\ntotal change in the use of Havoc throughout 2023.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 1 of 13\n\nThere was a 36% drop in use between Q2 and Q3 2023. This decline may be attributed to the waning novelty of\r\nbypassing Defender, as Microsoft consistently updates its security measures to safeguard users against emerging\r\nthreats. Toward the end of the year, there was a 22% increase in Havoc usage. This trend suggests that with\r\nongoing updates to Havoc and extensive research into other C2 frameworks, Havoc will inevitably be used more\r\nby threat actors.This graph was created and informed based on the Spamhaus Q2, Spamhaus Q3, and Spamhaus\r\nQ4 2023 threat reports.\r\nThreat hunting\r\nBecause defensive coverage isn’t very common right now for Havoc, it's important that defenders understand\r\nHavoc’s capabilities and equip themselves with the knowledge of detecting and analyzing Havoc, including its\r\ntraffic and generated artifacts. The Immersive Labs Cyber Threat Intelligence (CTI) team has closely examined\r\nHavoc and identified methods for incident responders to obtain both host-based and network-based indicators of\r\ncompromise (IoCs).This report details these technical findings and the detection engineering process used to\r\ndiscover them.\r\nThe range\r\nTo capture all of the traffic and artifacts necessary for analyzing the Havoc agents, we first set up a specialized\r\nrange made for detection engineering with high-fidelity log collection and EDR capabilities. This was deployed\r\nusing an Immersive Lab’s Cyber Range template. You can achieve the same outcome by manually deploying your\r\nown infrastructure, following Havoc C2’s documentation, and reading this report.The range had the following\r\nessential components:\r\nAn external host machine to deploy the agent (playing the attacker role)\r\nEvent logging\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 2 of 13\n\nSysmon\r\nElastic\r\nNetwork logging\r\nFull packet capture\r\nDNS logging\r\nTLS secrets\r\nEDR\r\nVelociraptor\r\nReset/restore\r\nWith our defensive range, called Heimdall, in place, we then had to deploy the attacker's infrastructure. All that\r\nwas required to run Havoc was a Kali Linux instance on a public IP address. Ubuntu 20.04/22.04, Debian-based\r\ndistributions, Arch distributions, and MacOS also work, though the steps to installing and setting up Havoc will\r\ndiffer based on the distribution you use. The Havoc installation documentation covers these differences. A single\r\nAWS EC2 (or similar) instance on a public IP address is all that’s needed, making it easy to open the required\r\nTCP, HTTP/S, and DNS ports to the range.\r\nHavoc teamserver\r\nThe Havoc C2 framework is split into two components: the teamserver and the client. The teamserver handles\r\nconnected offensive operators and manages the listeners, along with callback parsing and the downloading of\r\nscreenshots and files from the demon (agent). The client side is the user interface that operators will see; operators\r\ncan task the agent and receive outputs, such as command outputs, or loot. Loot is a term defined by Havoc and\r\nincludes screenshots and file downloads.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 3 of 13\n\nFor more details on how to use Havoc, please refer to Havoc's documentation.\r\nInstallation and configuration\r\nInstallation is pretty straightforward. Exact steps for installing, configuring, and creating payloads can be found in\r\nHavoc’s official documentation and GitHub repository.\r\nObtaining the encryption keys from the teamserver and database\r\nOur research aimed to identify reliable and repeatable ways to obtain encryption keys. Reverse engineering a\r\ndemon yielded no actionable results. We needed a way to determine what the keys were, so they could be used to\r\ndecrypt and examine memory and network traffic.To that end, we adopted the same technique we used in our\r\nSliver C2 research. Because Havoc is open source, we identified the source code responsible for generating the\r\nencryption keys and added print statements to the code.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 4 of 13\n\nUpon modifying aes.go, recompiling the teamserver, and running the demon, the keys were printed as standard\r\noutput.\r\nNow that we knew what the keys were, we used this knowledge to develop a methodology for obtaining the keys\r\nfrom packet captures and memory dumps.Another method we found was to obtain the keys from the database\r\nusing SQLite. This involves running sqlite3 from teamserver.db, and running the query below, replacing the\r\nAgentID with the agent ID of your demon.\r\nThe output below shows the Key and IV, but they are Base64 encoded.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 5 of 13\n\nAfter decoding, we get the keys.\r\nThese keys differ from those previously shown because we used two different demons to test these methods.\r\nHowever, using the methods described above will always print the keys.\r\nObtaining the encryption keys from packet capture\r\nHaving obtained the keys, we then developed a methodology to help defensive operators acquire them from both\r\npacket capture and memory, detailed below. After setting everything up, we ran the demon on the target machine\r\nwith Wireshark packet capture enabled. This allowed us to monitor all the HTTP and TCP traffic between the\r\ndemon and the teamserver.Upon analyzing the first packet in the capture, we noticed that the first bytes said dead\r\nbeef, which is a magic byte value, shown in the red box in the picture below.\r\nUpon checking the Havoc C2 GitHub repository, we identified the definition of the 0xDEADBEEF magic value,\r\nfound in the Defines.h file.\r\nHavoc uses a standard polling technique known as beaconing, where the agent checks in with the teamserver at\r\nregular intervals. This interval is set by the C2 operator as a sleep time value. Identifying C2 communications in\r\npacket capture can be characterized by identifying this beaconing behavior.For Havoc, the request to the server\r\ncontains the response from any commands or a request for any jobs. The response from the server to the client\r\ncontains the next task the implant is being instructed to execute, for example, to run a shell command. Going\r\nfurther through the packets, we see continuous communications of a POST request and an HTTP status code 200\r\nacknowledgment. This is a transmission where the demon checks in with the teamserver. These are continuous\r\nrequests; their cadence is dictated by the sleep time set on the agent, where it encrypts itself in memory to avoid\r\ndetection.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 6 of 13\n\nThe default sleep value is two seconds, but this is easily changed by the attacker. To avoid being detected in\r\nmemory by EDRs, Havoc implements a sleep technique that encrypts its own payload in memory. These sleep\r\ntechniques include:\r\nFoliage – Creates a new thread, using NtApcQueueThread to queue a return-oriented programming\r\n(ROP) chain, encrypting the demon and delaying execution.\r\nEkko – Uses the RtlCreateTimer to queue an ROP chain that encrypts the demon in memory, delaying its\r\nexecution. This technique has a GitHub repository.\r\nWaitForSingleObjectEx – No obfuscation, just delays execution for the time the sleep is set for, default is\r\ntwo seconds.\r\nGoing through the packets in the capture, and using Wireshark's filter feature, we filtered on hex, searching for the\r\nencryption keys we got earlier from the teamserver. We also identified the agent ID, correlating this based on it\r\nbeing shown in the teamserver. This pattern has remained consistent with multiple tests with different agents using\r\ndifferent sleep technique configurations.The encryption keys appear to be sent in the first non-check-in HTTP\r\nPOST request from the agent to the teamserver, shown in the picture below, along with the magic byte header,\r\nagent length, and AgentID.\r\nDecrypting traffic\r\nTo identify the location of the traffic, we had to identify packets with a length that would dictate something more\r\nwas happening than a check-in or sharing of keys. We identified a POST packet with a length of 3673 bytes,\r\nwhich was the largest packet so far. At this point, we could only guess that this was a command. We needed a way\r\nto validate this hypothesis.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 7 of 13\n\nWe did this by copying the value and bringing it into CyberChef so we could attempt to use the keys to decrypt it\r\nand potentially see a command output. For CyberChef, we needed the encryption method (AES256), the key, IV,\r\nand the mode, which we knew was CTR, since the AESCrypt.h file from Havoc’s GitHub repository indicated as\r\nmuch.\r\nAdding these to CyberChef and decrypting got us nothing, until we started removing bytes one by one from the\r\nbeginning of the input, the picture below shows the command output that gets sent to the teamserver.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 8 of 13\n\nThe image below shows the rough location where the beginning of the output is located, based on the CyberChef\r\noutput.\r\nThe natural direction to go from here would be to try to discover commands in the pcap; however, this isn’t\r\npossible as they are sent via beacon object files (BOFS). The only known way to discover what commands an\r\nattacker used is to capture and decrypt outputs and draw an inference from them.We identified a number of the\r\ncommands being sent from the header field. However, a large number of features are implemented as BOFS, and\r\nall share the same command_id. This makes it difficult to understand the exact command being executed without\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 9 of 13\n\nanalyzing the BOF, or the response. We have released a tool that can be found in the GitHub repos, which extracts\r\nand saves all sent BOFS and their responses if you have the AES key.\r\nObtaining the encryption keys from memory\r\nWe started this process by grabbing the keys from the teamserver.db using sqlite3, as previously discussed in the\r\n‘Obtaining the encryption keys from the teamserver and database’ section. We also went to the victim\r\nmachine and dumped the memory.Then, we needed to find the process PID for our demon, called chrome-updater.exe, using Volatility. We did this using the command below against our memory dump file.\r\nWe can see the process PID is 5544.\r\nWith the process PID in hand, we can then dump the process memory for chrome-updater.exe.\r\nNext, we faced the memory dump for the chrome-updater.exe process. We opened it in a hex editor and began\r\nsearching for the keys.  We wanted to determine if the keys were present in memory and if they could be identified\r\nthrough a scannable, consistent structure.The answer to these questions is yes! We tested this a number of times\r\nand came to the same result, as shown in the picture below.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 10 of 13\n\nThe structure is exactly the same both in memory and packet capture, specifically as below.\r\nDE AD BE EF is the magic signature for Havoc, and while it can be modified in source, it is the default value.\r\nThe next four bytes are actually the AgentID, and 00 63  is the DEMON INIT command sent from the client to\r\nthe team server.\r\nDetecting Havoc C2 in memory\r\nWith a reliable method established for obtaining encryption and IV keys from packet capture and memory, a\r\nYARA rule was created to specifically detect demon INIT requests in memory.\r\nWe have also created a Volatility plugin for detecting Havoc C2 in memory, which can be found in our GitHub\r\nrepository. An example of the expected output is shown in the picture below. This structure isn’t deleted from\r\nmemory, so rules could be run retroactively to identify Havoc agent actions.\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 11 of 13\n\nWe have also created a Python script to parse Havoc C2 traffic from a packet capture. The requirements for use\r\nare in the GitHub repository.The script requires either that the C2 traffic was sent over HTTP or that you can\r\ndecrypt the TLS layer of the HTTPS traffic using something like TLS MASTER secrets. The Heimdall range is\r\ndesigned to save all these secrets for pcap decryption. If you didn’t have the first packet where the encryption keys\r\nare, you could get the keys from memory, as previously discussed, and use them to decrypt the packet capture\r\ntraffic.An example of the expected output can be found below.\r\nDetecting Havoc C2 in using SIEM\r\nThis was one area of the research that yielded limited information. As previously mentioned, commands sent from\r\nthe teamserver to the demon are contained inside BOFS; searching for any indication of this communication in\r\nElastic yields no actionable results.If an attacker chooses to send shell commands from the teamserver, such as the\r\ncommand below, you’d be able to pick it up in Elastic with PacketBeat enabled.\r\nIn the context of Havoc, a shell or PowerShell command is specified by the attacker, and this opens cmd  exe or\r\npowershell  exe, respectively. They then run commands on the target machine in the context of a local cmd  exe\r\nor powershell  exe session. Therefore, it would get picked up in Windows Event Logging, Security Logs, Elastic,\r\nor your SIEM of choice.If an attacker opts for stealth, they’ll run their commands without a shell, therefore as\r\nBOFs. With our Elastic setup, we couldn’t retrieve details about commands executed and stored in BOFs. The\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 12 of 13\n\nonly way we found to capture commands was if the attacker ran their commands to the agent through cmd  exe  or\r\nPowerShell, which they can specify from the team server.\r\nIf you’re an Immersive Labs CyberPro customer, you might enjoy our Havoc C2: Memory Forensics lab, a\r\nhands-on practical lab to test out the techniques in this research report.The Immersive Labs CTI team also\r\nresearched another C2 framework called Sliver. If you’re interested, check out the research blog post. If you're a\r\nCyberPro customer, have a look at the lab Sliver C2: Memory Forensics. We also have a Team Sim called\r\nDetecting Sliver, for those with Team Sim licensing.You can also find the detection engineering range without the\r\naddition of the attacker infrastructure in the Ranges Dashboard as the Heimdall Detection Engineering range.To\r\nlearn more about how Immersive Labs helps organizations assess, build, and prove cyber resilience, visit our\r\nResources Center.\r\nSource: https://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nhttps://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.immersivelabs.com/resources/blog/havoc-c2-framework-a-defensive-operators-guide"
	],
	"report_names": [
		"havoc-c2-framework-a-defensive-operators-guide"
	],
	"threat_actors": [],
	"ts_created_at": 1775434092,
	"ts_updated_at": 1775826699,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e47537269473e68bd0849c42fa5d5d7c142a687d.pdf",
		"text": "https://archive.orkl.eu/e47537269473e68bd0849c42fa5d5d7c142a687d.txt",
		"img": "https://archive.orkl.eu/e47537269473e68bd0849c42fa5d5d7c142a687d.jpg"
	}
}