Havoc Demon Hunting - Malware Analysis Lab

Hunting for Havoc Demons

Overview (AI generated from video):

Summary

Havoc is an offensive security tool that uses dynamic API resolution, and this video demonstrates how to create YARA rules to detect its implants.

Timestamps

[00:00] 🎥 Introduction to Havoc framework and its dynamic API resolution
[03:10] 🎯 Analyzing the Havoc implant sample in Ghidra
[05:45] 🔍 Identifying the dynamic API resolution and its impact on imports
[09:20] 🧩 Understanding the hashing algorithm and resolving APIs
[13:35] 📜 Creating YARA rules using byte patterns from the hashing function
[18:10] 🛠 Testing the YARA rule on samples and detecting Havoc implants
[21:05] 📊 Discussing the effectiveness of the YARA rule in malware detection

Key Insights

🧩 Dynamic API resolution allows the Havoc framework to run without directly importing any APIs, making it harder to detect.
🔍 Analyzing the Havoc implant sample in Ghidra reveals the use of indirect CIS calls and the absence of imports.
🎯 The thread environment block and process environment block play a crucial role in dynamic API resolution.
📜 The hashing algorithm in the Havoc framework is used to resolve APIs at runtime.
🛠 Creating YARA rules based on byte patterns from the hashing function can effectively detect Havoc implants.
📊 Testing the YARA rule on samples shows high detection rates, proving its efficiency in identifying Havoc malware.
🎥 This video provides a step-by-step guide on analyzing and creating YARA rules for Havoc implants.

Transcript (AI generated from video):

00:00:00	Havoc is an offensive security tool and post exploitation framework with command and control capabilities created by C Spider and the S is the letter five and it's freely available on GitHub now one aspect of this framework is that it uses indirect CIS calls and dynamic API resolution at runtime we've got this sample here which is of the Havoc framework now this is a particular implant and if I look at it through a tool such as PE bear you'll notice something of Interest this has no Imports there's absolutely no imported
00:00:34	apis directly from this executable yet it will run fine and the reason is because of that Dynamic API resolution so I'm going to go ahead and open up this executable with gidra so that we can get more of an idea of what's Happening under the hood so I'm just going to drag it into my project and I'm going to leave the default settings on you'll notice straight away it says delay Imports detected which aligns with what we saw with this not importing any kind of DLS or apis so let's hit okay and let's double click on it when it
00:01:01	loads what we're going to do is analyze it so we're just going to hit yes and this is going to analyze and we're just going to keep the defaults on so let's hit analyze you'll notice straight away on the right hand side if you've got the strings window open is that demon. x64.exe has been found you'll also notice that there are these other string values that have just been found I'm just going to hit yes and go to the entry point now the other string values that are found are a little bit interesting because whenever you've got
00:01:30	a string string value that mentions something like system 32 and sisw 64 in the context of maare analysis this is defining the executable that it's going to be injected into for that particular implant now there is also a mention of something that looks like a user agent so this is likely a forgi user agent that's going to be used in command and control activity and there is that demon. x64.exe demon is the standard name of the implants used by the Havoc framework so let's go to the entry point one of
00:02:00	the way that we can do that is just hitting G and going entry and that's going to take us right there now one of the things that we can begin to do at the start of analysis is understand the calls that occur so we can hit display function call trees and down the bottom that's going to give us any incoming or outgoing calls from the entry point now because this is using some sort of dynamic API resolution one of the things that I might want to look for is calls to the GS or the segment register and
00:02:32	the reason is because this contains something known as the thread environment block or the thread information block and that's going to contain something known as the process environment block or the PEB and this is going to have pointers to structures that allow us to do stuff like resolve apis let's take a search and I'm I'm just going to search through the program text I'm just going to hit GS and just search for that for the time being and we're going to look for probably all fields and just hit search
00:03:02	all now we got three hits back all of which relate to GS and zx30 so the offset of 0 x30 when it's added to the segment register address is going to get the thread environment block and this is going to be able to be used in order to resolve apis this is a little bit interesting this might actually explain why we're not seeing any kind of imported functions cuz they're done at runtime let's follow along and straight away if you follow the first one you will notice some interesting values 0x and then a string and this goes on
00:03:39	almost like it's running in a loop and what it's actually doing is resolving the apis that are necessary for the rest of this to function and so if we look at the Havoc framework so I've just got it downloaded from GitHub here and we look at the payloads and we look at the demon and we look at the source we have the demon. C file it gives you a good idea of the process that needs to be taken here so it needs to initialize the pointer the modules and the windows 32 API before it can do anything and so if we actually look at
00:04:13	how that's done in Demon main there is this call to the demon routine at the end here but first off there is instance being defined on the stack and then the demon in it so if we go down to the demon init method you'll notice that what it does does is it's resolving all of the different modules it's got all these loader function address that's being used in order to get the different apis and because we know that this is actually related to the hashing algorithm and resolving those apis if we go down this is actually going to run in
00:04:49	order of exactly what we see in the code on GitHub so the first hash is going to resolve to ntdll and then the next one is going to resolve to loader get procedure address and then the next one is loader load dll and so on and so forth now if we look carefully you'll notice that on the left hand side we actually have the raw assembly values so that the hexad decimal that's being used to interpret this instruction if we actually look at it backwards so we have this 70 e uh 70 e61 1753 we have 70 E6
00:05:31	1753 backwards and these constants can actually be used to build out Yara rules that's able to detect this C2 framework or at least the hashes tied to API calls used by this particular framework so this is actually quite useful and this is actually something similar to what MB research has done definitely go and check out his stuff I'll link it in the description below but let's see how we can turn a this information into a Yara rule that's then going to be able to detect more variants of the Havoc C2
00:06:02	framework loaders or demon executable so I've started up a template here that can be used and first off we just have some comments so this just gives a little bit of metadata but we don't actually need this we also have the actual metadata associated with the Yara rule so in this particular case I'm just going to give it a description one of the things that I've included is mention of a hash and so there is actually a virus total Yara C that can be used with your GitHub repository to essentially test your
00:06:35	rules and see if they hit on particular binaries based on their hash so in this particular case I've included the hash so that when it gets committed to GitHub it's going to run the checks against it sitting on virus total and confirm that it actually detects on this malware now one of the things that I want to do is actually create the rule though so we've got pretty much all the metadata that we need associated with this and now what I want to do is actually look at the bite patterns if we open this up in gidra
00:07:05	once more what I actually want to be using is heximal values so if you're creating a normal Yara rule you can specify a variable in this particular case this could be string one equals test asky wide and so the asy and wide modifiers are used to determine whether it's going to detect on asy strings or Unicode strings in the binary so what this means is it's actually detecting on both asy and unicode strings in the binary now what does that actually mean well if we look at our sample it's a it's a great way to demonstrate the
00:07:41	difference so we do have this asky string which is demon. 64.exe that is within the binary but then if we look at something like our user agent you'll notice that this is actually Unicode so we have null bytes in between each character which means that if we're not looking for wide we're not going to pick up on this full string and I'll prove it to you we have notepad.exe and now this uses uni code so what I'm going to do is I'm going to change this to notepad.exe and we're going to get rid of the wide
00:08:13	modifier so we're only looking in asky strings now I'm going to make this all of them now I'm going to open up Yara so on the desktop I'm going to run Yara this is just called Yara template and now I'm going to specify what I'm actually running this again so we have our havoc and we have our executable here now if this hits we will have it bounce back to show that it actually hit on the rule but there was nothing there was nothing that bounced back now let's modify this to wide so it's looking for
00:08:39	both those types of strings and now suddenly you'll see it bounces back and says win Havoc C2 demon hashing to say this binary matched on our Yara now we actually don't want to be looking for these strings what we want to be looking for is the hashing routines so we're actually going to use the btes in the hashing function as opposed to using a string to do that we're going to go back let's go to our entry point let's go into our function let's find the function that does the resolutions and we've got them here and
00:09:10	really we want this value of the API hash let's take this bite string here and we only want that value so it's 53 up to 70 53 up to 70 now the way that we actually specify bites as opposed to strings in the AR rule is through the curly braces so it would look some something like this so this would be API 1 and we could do this for every string right so there's API 1 API 2 would be the next one so go down up to B6 then we have API 3 etc etc etc all right I'm just going to go through and create this and comment it so let's do a
00:09:56	time lapse as I'm going through I just realized that uh there's that they resolve anti Crea ENT twise well I guess I could make a pool request and become a contributor but I don't really want to worth noting that you probably don't need this amount but it's always good to have I guess feel like I miss some with a copy and paste because there's also this one P4 C9 and I don't actually know which one that is I think I I think I miss some or doubled up here so they might actually be accurate with what they resolve to
00:12:35	but nonetheless they're pretty close so all right so I feel like maybe I duplicated some of the bite patterns or doubled up or something because there are a couple left over that one and that one before we reach the end of that routine which I I didn't have a name for so I might have might have messed up with some of this copy and base I mean there's already in which one of these is doubled up there right there that's a double up right there which means everything needs to shift by one and just like that we have all of 59 of the
00:13:23	hashes that are being resolved and what they resolve too by comparing them to the demon. C code on GitHub we actually have a complete rule here now I know it's still called Yara template but we could just look for in in this particular case I've just put any four of these coming up to actually find samples that work in pretty much the exact same way unless they are actually just other Havoc samples so let's give it a shot I will just say I've got to get rid of any any isn't isn't an accurate word here we just need to say
00:13:58	and four of them nice my rule compiled it worked I'm going to give it a scan and so my scan has finished on on unpack me and I have 10 matches in a 12we look back period so we got 100% coverage and you can see it is also hitting on these other win Havoc rules so w0 W1 these were the rules that were created by MB research so I know that there's a pretty good chance that we've done similar thing to detect this malware but we've just got our one rule and we've picked up on all of these so that's pretty
00:14:33	great and so I'm going to run a scan as well through hybrid analysis we'll run a hunt and so you can see straight away we have now 19 files that have come back and we've got 10 out of 306 64 malware and there's plenty of malicious samples that have come up here you can see demon 64.exe as well if we go across a couple of pages all these malicious go to some of the further Pages malicious malicious this has no specific threat found so this might actually be a little bit interesting to take the sample and just
00:15:08	see what it's actually hitting on and why it hasn't been flagged here and also just compare it on something like virus total you can see that even though this came up clean using hybrid analysis it's actually malicious and a Shell Code loader for Havoc C2 as well so we're looking good everything that we are actually looking at here this are the deal variant we're actually picking up on this malware so we've just created a pretty comprehensive Yara rule to detect this malware and likeminded malicious
00:15:40	samples and we haven't had to go through too much effort and if we go back to our sandbox we can run that same rule against the Havoc sample and we can see that it hit we can also use a Tac s and this is going to elaborate on every single hit in the sample so we can see that every single one of our API hash is match every single one of our B string that we're looking for match and we're good to go we've got a Yara rule that can be used pretty much in production now that's it that's all I wanted to
00:16:08	show you today uncovered how you can go about creating Yara rules that use bite strings by looking at binaries that use Dynamic API resolution within gidra and using that to our advantage any questions comments feelings thoughts anything else in the comment section below and I will catch you next time [Music]