{
	"id": "cc44b4d9-26bf-428c-a482-94deea09b34c",
	"created_at": "2026-04-06T00:15:23.205404Z",
	"updated_at": "2026-04-10T03:21:22.992706Z",
	"deleted_at": null,
	"sha1_hash": "76dab44d88cf32c87d9f758670dd55526c8a33e1",
	"title": "Havoc Across the Cyberspace | Blog | Zscaler",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5988860,
	"plain_text": "Havoc Across the Cyberspace | Blog | Zscaler\r\nBy Niraj Shivtarkar, Shatak Jain\r\nPublished: 2023-02-14 · Archived: 2026-04-05 19:42:43 UTC\r\nInfection Chain Analysis\r\nFig 2. Infection chain\r\nThe infection chain utilized by the threat actors for delivering the Havoc Demon on the target machines\r\ncommences with a ZIP Archive named “ZeroTwo.zip” consisting of two files “character.scr” and “Untitled\r\nDocument.docx” as shown in the screenshot below.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 1 of 20\n\nFig 3. ZIP Archive\r\nHere the “Untitled Document.docx” is a document consisting of paragraphs regarding the “ZeroTwo” which is a\r\nfictional character in the Japanese anime television series Darling in the Franxx.\r\nFig 4. Contents of the Document bundled in the ZIP Archive\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 2 of 20\n\nFurther the screen saver file “character.scr” is basically a downloader commissioned to download and execute the\r\nHavoc Demon Agent on the victim machine. The Downloader binary is compiled using a BAT to EXE converter\r\n“BAT2EXE” which allows users to convert Batch scripts into executables as shown in the screenshot below. The\r\nBAT2EXE argument can be seen in the downloader binary.\r\nFig 5. BAT2EXE argument used in the downloader binary\r\nOnce executed the BAT2EXE compiled binary loads and decrypts the Batch Script from the .rsrc section as shown\r\nin the screenshot below.\r\nFig 6. Decrypted BAT Script\r\nThe binary then writes and executes the decrypted BAT script from the Temp folder as shown in the image below.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 3 of 20\n\nFig 7. Decrypted BAT Script written in the Temp folder\r\nThe Decrypted BAT Script upon execution performs the following tasks:\r\nChecks whether “teste.exe” exists in the Temp folder, if not, it downloads the final payload from\r\nhttp[:]//146[.]190[.]48[.]229/pics.exe and saves it as “seethe.exe” in the Temp folder via Invoke-WebRequest and\r\nthen executes it using “start seethe.exe”\r\nFig 8. Downloads the final payload “pics.exe” from remote server via Invoke-WebRequest\r\nThen it checks whether “testv.exe” exists in the Temp folder, if not, it downloads an image from\r\n“https[:]//i[.]pinimg[.]com/originals/d4/20/66/d42066e9f8c4b75a0723b8778c370f1d.jpg” and saves it as\r\nimages.jpg in the Temp folder and opens it using images.jpg.\r\n     \r\nFig 9. Downloads a JPG image from pinimg[.]com\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 4 of 20\n\nThe following image of the “Zero Two” character was downloaded from pinimg[.]com \u0026 executed in order to\r\nconceal the actual execution and malicious activities performed by the final payload.\r\nFig 10. Zero Two Image downloaded from pinimg[.]com\r\nBefore analyzing the final payload, let’s take a look at another similar Downloader compiled via BAT2EXE\r\nnamed “ihatemylife.exe”, in this case, the decrypted Batch script downloads the final payload from\r\n“https[:]//ttwweatterarartgea[.]ga/image[.]exe” using Invoke-WebRequest alongside the payload it also downloads\r\nan image to conceal the malicious activities as shown in the screenshot below. \r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 5 of 20\n\nFig 11. Decrypted Batch scripts downloads the final payload from https[:]//ttwweatterarartgea[.]ga\r\nFig 12. Image Downloaded by the Batch Script to conceal malicious activities\r\nNow let’s analyze the final In-the-Wild “Havoc Demon” payload which was downloaded via the Downloader\r\nnamed “character.scr” from http[:]//146[.]190[.]48[.]229/pics.exe as explained previously.\r\nHavoc Demon is the implant generated via the Havoc Framework - which is a modern and malleable post-exploitation command and control framework created by @C5pider.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 6 of 20\n\nFig 13. The Havoc Framework\r\nFig 14. Havoc Framework - Interface\r\nShellcode Loader\r\nThe Downloaded payload “pics.exe” is the “Shellcode Loader” which is signed using Microsoft’s Digital\r\ncertificate as shown in the screenshot below.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 7 of 20\n\nFig 15. Microsoft Signed Executable\r\nUpon execution the Shellcode Loader at first disables the Event Tracing for Windows (ETW) by patching the\r\nWinApi “EtwEventWrite()” which is responsible for writing an event. ETW Patching process:\r\nRetrieves module handle of ntdll.dll via GetModuleHandleA\r\nRetrieves address of EtwEventWrite via GetProcAddress\r\nFig 16. Fetches the address of EtwEventWrite\r\nFurther it changes the protection of the region via VirtualProtect and then overwrites the first 4 bytes of the\r\nEtwEventWrite with following bytes: 0x48,0x33,0xc0,0xc3 (xor rax,rax | ret)\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 8 of 20\n\nFig 17. Overwriting bytes to patch EtwEventWrite\r\nBy patching the EtwEventWrite function the ETW will not be able to write any events thus disabling the ETW.\r\nThen the payload AES decrypts the shellcode using CryptDecrypt() as shown in the screenshot below - in this case\r\nthe Algorithm ID used is “0x00006610” - AES256\r\nFig 18. AES Decrypts the Shellcode via CryptDecrypt\r\nOnce the Shellcode is decrypted, the Shellcode is executed via CreateThreadpoolWait() where at first it creates\r\nan event object in a signaled state via CreateEventA(), then allocates RWX memory via VirtualAlloc() and writes\r\nthe Shellcode in the allocated memory. Further it creates a wait object using CreateThreadpoolWait, here the first\r\nargument - callback function is set to the address of the shellcode. Then it set’s the wait object via the NtApi\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 9 of 20\n\n“TpSetWait” and at last calls the WaitForSingleObject which once executed checks if the waitable object is in\r\nsignaled state, as our event was created in signaled state the callback function is been executed i.e the decrypted\r\nshellcode is been executed and the control flow is been transferred to the shellcode.\r\nFig 19. Shellcode execution via CreateThreadpoolWait\r\nKaynLdr - Shellcode\r\nThe Shellcode in this case is the “KaynLdr” which is commissioned to reflectively load the Havoc’s Demon DLL\r\nimplant by calling its entrypoint function. Once the Shellcode is executed it retrieves the image base of the Demon\r\nDLL which is embedded in the shellcode itself by executing the following inline assembly function called\r\nKaynCaller.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 10 of 20\n\nFig 20. Retrieves the Image Base of the Embedded Demon DLL\r\nFurther the KaynLdr performs the API Hashing routine in order to resolve the virtual addresses of various\r\nNTAPI’s by walking the export address table of the ntdll.dll (Function: LdrFunctionAddr) and initially the virtual\r\naddress of the NTDLL.dll is been retrieved by walking the Process Environment Block (Function:\r\nLdrFunctionAddr) as shown in the screenshot below\r\nFig 21. API Hashing Routine used by Havoc Demon\r\nHere the hashing algorithm used is a modified version of “DJB2” algorithm based on the constant “5381” or\r\n“0x1505” as shown in the screenshot below.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 11 of 20\n\nFig 22. Modified DJB2 Hashing Algorithm used in the API Hashing Routine\r\nVirtual Addresses for the following module and NTAPI’s are retrieved by using the API Hashing routine where the\r\nhardcoded DJB2 hashes are compared with the dynamically generated hash.\r\n0x70e61753 ntdll.dll\r\n0x9e456a43 LdrLoadDll\r\n0xf783b8ec NtAllocateVirtualMemory\r\n0x50e92888 NtProtectVirtualMemory\r\nFurther the Embedded Demon DLL is memory mapped and the base relocations are calculated if required in an\r\nallocated memory page procured by calling the NtAllocateVirtualMemory(). Also the page protections are\r\nchanged via multiple calls to NtProtectVirtualMemory as shown below.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 12 of 20\n\nFig 23. Memory Mapping of the embedded Demon DLL\r\nThe Demon DLL is memory mapped in the Allocated memory without the DOS and NT Headers in order to evade\r\ndetection mechanisms.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 13 of 20\n\nFig 24. Demon DLL is memory mapped without DOS and NT Headers\r\nNow once the Demon DLL is memory mapped the KaynDllMain i.e the entrypoint of the DLL is executed by the\r\nKaynLdr as shown below, from there on the control is transferred to the Havoc Demon DLL Implant.\r\nFig 25. Entrypoint of the Demon DLL is been executed by the KaynLdr\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 14 of 20\n\nAnalysis of Havoc Demon DLL\r\nThe entrypoint of the Havoc Demon DLL is executed by the KaynLdr as discussed previously. Now as the Havoc\r\nDemon has many features, we will only focus on a few of them in the following blog, as the features can be\r\ndeduced from its source at: https://github.com/HavocFramework/Havoc\r\nSo once the Havoc Demon is been executed there are four functions which are been executed by the\r\nDemonMain(): \r\nDemonInit\r\nDemonMetaData\r\nDemonConfig\r\nDemonRoutine\r\nThe DemonInit is the initialization function which\r\nRetrieves the virtual addresses of functions from modules such as ntdll.dll/kernel32.dll by calling the API\r\nHashing Routine discussed previously.\r\nRetrevies Syscall stubs for various NTAPI’s\r\nLoads various Modules via walking the PEB with stacked strings\r\nInitialize Session and Config Objects such as Demon AgentID, ProcessArch etc.\r\nNow let’s understand how the Configuration is being parsed via the DemonConfig() function.\r\nThe Demon’s Configuration is been stored in the .data section as shown in the screenshot below\r\nFig 26. Demon Configuration stored in the .data section\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 15 of 20\n\nThe DemonConfig function parses the configuration by indexing the various required values from the config.\r\nFollowing is the configuration for the Demon DLL used in the campaign.\r\nConfiguration:\r\nSleep: 2 (0x2)\r\nInjection: \r\nAllocate: Native/Syscall (0x2)\r\nExecute: Native/Syscall (0x2)\r\nSpawn:\r\nx64: C:\\Windows\\System32\\notepad.exe\r\nx86: C:\\Windows\\SysWOW64\\notepad.exe\r\nSleep Obfuscation Technique: Ekko (0x2)\r\nMethod: POST\r\nHost: 146[.]190[.]48[.]229\r\nTransport Secure: TRUE\r\nUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537/36 (KHTML, like Gecko)\r\nChrome/96.0.4664.110 Safari/537.36\r\nFig 27. Demon Configuration - Host (CnC) and UserAgent parsed\r\nThe DemonRoutine() function is the main loop for the malware, it is responsible for connecting to the command\r\nand control (C2) server, waiting for tasks from the server, executing those tasks, and then waiting again for more\r\ntasks and running indefinitely. It does the following things:\r\nFirst, it checks if it is connected to the C2 server. If not, it calls TransportInit() to connect to the server.\r\nIf the connection is successful, it enters the CommandDispatcher() function, which is responsible for a task\r\nroutine which parses the tasks and executes them until there are no more tasks in the queue.\r\nIf the malware is unable to connect to the C2 server, it will keep trying to connect to the server again\r\nNow let’s understand how it connects to the TransportInit function:\r\nTransportInit() is responsible for connecting to the C2 server and establishing a session. It first sends the AES\r\nencrypted MetaData packet i.e the Check-in request generated via the DemonMetaData() function through the\r\nPackageTransmit() function, which could be sending data over HTTP or SMB, depending on the value of the\r\nTRANSPORT_HTTP or TRANSPORT_SMB macro. If the transmission is successful, it then decrypts the\r\nreceived data using AES encryption with a given key and initialization vector on the TeamServer. The decrypted\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 16 of 20\n\ndata is then checked against the agent's ID, and if they match, the session is marked as connected and the function\r\nreturns true.\r\nFig 28. Metadata Structure - CheckIn Request\r\nTransportSend() is used to send data to the C2 server. It takes a pointer to the data and its size as input, and\r\noptionally returns received data and its size.It then creates a buffer with the data to be sent, and depending on the\r\ntransport method, it either sends the data over HTTP or SMB.\r\nFig 29. TransportSend Function Arguments With Encrypted Data of the Check In request\r\nOn the Teamserver end the CheckIn request with the metadata packet is been decrypted and showcased on the\r\nterminal with both encrypted and decrypted details of packets sent and received.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 17 of 20\n\nFig 30. Check In Request - Metadata packet parsed by the Team Server\r\nCommand Execution:\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 18 of 20\n\nAfter the demon is deployed successfully on the target’s machine, the server is able to execute various commands\r\non the target system. If the command \"whoami\" is issued to the payload, it would trigger the execution of the\r\ncommand and display the current user running the session.The server logs the command and its response upon\r\nexecution.\r\nFig 31. Command execution using Havoc GUI\r\nOnce the command is executed on the victim machine, the command output is AES Encrypted and then sent to the\r\nCnC server, which is then decrypted by the TeamServer as shown in the screenshot below.\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 19 of 20\n\nFig 32. Command Output Logs parsed by the TeamServer\r\nList Of Commands:\r\nThe specific commands available in Havoc will depend on the version and configuration of the framework, but\r\nsome common commands that are often included in C2 frameworks include:\r\nFig 33. Commands List\r\nFurther the Demon implements various techniques mentioned below which can be analyzed from the source:\r\nReturn Address Stack Spoofing\r\nIn-Direct Syscalls\r\nSleep Masking Techniques\r\nEkko\r\nFOLIAGE\r\nWaitForSingleObjectEx\r\nExplore more Zscaler blogs\r\nSource: https://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nhttps://www.zscaler.com/blogs/security-research/havoc-across-cyberspace\r\nPage 20 of 20\n\n  https://www.zscaler.com/blogs/security-research/havoc-across-cyberspace  \nFig 30. Check In Request -Metadata packet parsed by the Team Server\nCommand Execution:   \n   Page 18 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/havoc-across-cyberspace"
	],
	"report_names": [
		"havoc-across-cyberspace"
	],
	"threat_actors": [],
	"ts_created_at": 1775434523,
	"ts_updated_at": 1775791282,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/76dab44d88cf32c87d9f758670dd55526c8a33e1.pdf",
		"text": "https://archive.orkl.eu/76dab44d88cf32c87d9f758670dd55526c8a33e1.txt",
		"img": "https://archive.orkl.eu/76dab44d88cf32c87d9f758670dd55526c8a33e1.jpg"
	}
}