IDAT Loader - Malware Analysis Lab
Part 1: DLL Side-Loading into Antivirus Software
Overview (AI generated from video):
Summary
Antivirus software can run malware on systems due to vulnerabilities like DLL side loading and DLL search order hijacking, which allow malicious DLLs to be executed instead of legitimate ones.
Timestamps
0:21 📅 Antivirus software can run malware on systems due to vulnerabilities like DLL side loading and DLL search order hijacking.
1:07 🧩 A DLL is a dynamic link library that contains code shared across different software.
2:20 🚧 DLL search order hijacking occurs when a malicious DLL is placed in a directory where a legitimate executable is looking for a DLL.
4:02 📊 DLL side loading used to refer to malicious DLLs in C Windows winsxs, but now it can also be a DLL in the same directory as a legitimate executable.
5:29 🔎 Some software trusts that it will find the right DLL when executed, making it vulnerable to running malicious code.
7:10 👥 Malicious DLLs can be disguised as legitimate ones with matching names, descriptions, and version details.
8:35 📝 Malware like IDAT injector and IDAT loader use techniques like steganography, DLL search order hijacking, and encryption to remain undetected.
Key Insights
DLL side loading and DLL search order hijacking are vulnerabilities in Windows that allow malicious DLLs to be executed instead of legitimate ones. This can happen when a malicious DLL is placed in a directory where a legitimate executable is looking for a DLL. 🚧
Antivirus software can inadvertently run malware on systems due to these vulnerabilities, as the software trusts that it will find the correct DLL when executed. This trust can be exploited by malicious actors. 🔐
Malicious DLLs can be disguised as legitimate ones by giving them matching names, descriptions, and version details. This makes it difficult for antivirus software to detect them as threats. 🎭
IDAT injector and IDAT loader are examples of malware that use techniques like steganography, DLL search order hijacking, and encryption to remain undetected. These techniques allow them to hide their malicious code within legitimate files and execute it without being detected. 🕵️♀️
Reverse engineering and analysis of malware can uncover their techniques and reveal how they work. This knowledge is crucial for developing effective countermeasures and protecting systems against such threats. 🔍
Transcript (AI generated from video):
00:00:00 antivirus software can run malware on your systems but to understand why this is possible I'm going to have to explain a few Concepts first off dlll side loading and dll search order hijacking now a dll on Windows is a dynamic link Library so what that is is some code that's being shared across different pieces of software so for example I have this software here which is notepad++ however it has a malicious dll next to it which is this debug help. DL so when I run it there's a popup that says all
00:00:38 your Bas are belong to us and it shows that the dll has been executed by this particular process and if we press okay then it pops up all right it runs as normal and it spawns calculator now this is a DL that I created just for the purpose of this video and actually if I move it into this directory and run the executable again it runs as normal but we don't get the popup it doesn't load that dll and everything seems to be running like normal how does this work on Windows there is something known as a
00:01:09 search order now if you don't specify where a library is that you wish to load it's going to check through these different locations by default and if it finds something with that name it's going to load it now there's an inherent trust in notepad plus plus that sees this debug help D and says this must be what we're looking for this is all good debug. DL is a legitimate Windows DL it's actually sitting within the C Windows system 32 directory because I have put my dll in a location that it's looking for before this dll it gets
00:01:43 executed instead of this dll thus running my malicious code instead of the code that it was meant to run now this is dll search order hijacking nowadays it might also be commonly referred to as dll sideloading it used to be that dll sideloading had a little bit of a difference to dll search order hijacking the difference is basically that it was for dlls sitting in C windows winsxs so this is side by side that's what it stands for Windows side by side so the dlls in directories here were where the term side loing came from you
00:02:20 would plant a malicious D in one of these directories and what Windows would do was that if there was compatibility issues or it needed a certain version of a DL there stored in here so that's side loading but nowadays side loading can just be thought of as a malicious DL in the same directory as a legitimate executable that is then going to be loaded now that we know a bit about dll side loading and dll search order hijacking let's take a look at some of the software trust where they just think
00:02:48 they're going to find the right dll when they execute now there is a particular sample that I've located and it does have this setup.exe but if we highlight over it it's actually called Windows Defender Advanced threat protection sense C which is the categorization engine I believe and this has a malicious DL MP gear. dll but you'll notice that the description here is also Microsoft antimalware utility library and it seems to have the right Corporation details and it even has the right version details in fact if we
00:03:23 compare these two samples side by side on virus total you'll notice something pretty interesting on the left hand side we have the legitimate version which is yep distributed by Microsoft no issues there and on the right hand side we have a malicious version so let's look at the detection if we look at the details the md5 sums don't match neither to the sh 1 sh 256 this is all stuff that we would expect because the files are different but the Vash matches the Imp has matches because it has the same imported
00:03:54 functions the rich PE header matches the SS deep almost the SSD almost matches look at the creation timestamps everything matches up look at the names Associated the signature verification details it's the same the difference is that this signature doesn't verify because the code has been changed and this signature does verify because the code hasn't been changed even if you go down to the sections the sections in the entropy they're almost identical even with the md5's of them the Imports the exports almost almost the exact same
00:04:31 I've even got them side by side in PE Studio the number of btes is identical the descriptions identical file version all of this because they've taken the legitimate dll and just chopped the code in it let's go ahead and take a look at this and see how it works and see what it is so I've gone ahead and opened up both the legitimate and the malicious DL and on the right hand side the malicious one you can see that it actually takes four parameters whereas on the left hand side the legitimate one only takes three
00:05:04 parameters on the left hand side there is the the function so I want to explore that so we're on the same function on both and maybe if we just go down a bit you will notice something of Interest this is the malicious one this is the legitimate one the parameter 4 seems to be used in this function here now this function is not got parameter 4 on the legitimate one so let's go ahead and and just take a look at that and now if we look through these different pieces of code there's a lot more code on the
00:05:38 malicious one than there is on the leftand side now on the left hand side there are calls to other functions so you'll notice that there's calls to other functions there but on the malicious dll there actually isn't any calls to other functions and if we look there's no outgoing references but there are outgoing references on on the legitimate one so we actually have a case where all the malicious code is likely sitting in this function here the rest of the code in the dll is never going to be called it's just going to
00:06:11 use what's in this one and obviously this doesn't break the executable in any particular way because it seems to still run and function now this malware has a couple of different components but in general it's known as idat injector and idat loader and this is the name given to it by rapid 7 but to other security companies it might be known as hijack loader thanks to the rapid 7 report we know that idat loader gets its name because it stores its payload in an idat chunk now an idat chunk is part of a PNG
00:06:45 file it's stuff that make up a PNG picture file however if we look in this directory there's nothing here that says it's a PNG file let's take a look at detected easy on this SVG file though it actually identifies as a PNG file cuz this has a Mas rated extension so what would actually happen if we rename this from SVG to PNG okay so it looks like there's actually part of a picture and if we view this it seems okay the top part is a picture and then maybe there's some corrupted bites and so if we view
00:07:18 the file in a heximal editor we can see a PNG header we can see reference to idat streams however we know that there's something hidden here some sort of steganography going on we have to actually look for an idat stream followed by a particular secret key now that particular secret key is actually hex value of C6 A5 79 EA and so if we search for this this is actually following an idat stream so that's actually what we needed the four bytes following that would be C7 8 e13 EF are actually going to be our key to decrypt
00:07:57 this payload so if we open this up in cyber Chef this is an exor key that's going to be used we're just going to throw that in here so we don't forget and we're going to get rid of the spaces cuz we don't need them so let's just disable this and go back to our hex editor so everything following those that key all the way down to the bottom let's take the lock is going to have this operation where it does a bitwise exclusive or operation on these bites and transforms them once we put that key in and have it from hex first that we
00:08:30 begin to see some characters that are kind of strings that make sense so let's actually remove our null bites we can see stuff like wind sisw 64 cmd.exe by the looks of things there does seem to be this can value thrown in there but then we can also see what looks to be Ms html. dll as well and so if I saw something like this and I didn't have any idea of what it was doing I would lean towards perhaps it's is doing some sort of injection just simply because we see mention of sisw 64 and the cmd.exe
00:09:06 executable now we actually know from the rapid 7 report that what this is doing is it's having the command prompt executable load the Microsoft html. dll and then what it's doing is it actually rewrites part of the text section of that dll with the D compressed code and the decrypted code and then it runs that directly from memory so it's essentially hollowing out part of that dll to allow it to run without kind of blowing away the entirety of the dll which is kind of interesting the way that that works but
00:09:40 if we look further at the decrypted code that we have here what we could actually do is use something like strings and maybe just crank this up to a minimum length of about seven and we can begin to see some more strings that might be of interest so for example we can see this program cannot be run in DOS mode so there's likely actually a portable executable within the decrypted data that is then going to be loaded into memory and the fact that this is using combinations of steganography dll search
00:10:10 order hijacking encryption in order to remain undetected is quite interesting hi everyone it's j here from the future so at this point in time I realized that I go really into the weeds with reverse engineering this malware and what I'm going to do is save that for next week's video so if you got any thoughts feelings queries anything else leave it in the comments section below and I will catch you next time [Music]
Part 2: Technical Analysis of IDAT Loader
Overview (AI generated from video):
Summary
Video script expert provides a walkthrough of malware analysis using x32dbg, Ghidra, and IDA to reverse engineer a hijack loader/injector. Highlights
0:28 ⏱️ The malware spawns a child process of Windows command prompt from the syswow64 directory, which is of interest for further analysis.
1:38 ⏱️ The malware injects into explorer.exe and spawns a command prompt process, indicating a potential compromise.
3:58 ⏱️ Using x64dbg, the expert sets breakpoints on module loads and commonly used process injection APIs like VirtualProtect and WriteProcessMemory.
5:45 ⏱️ In the injected process, the expert identifies shellcode and analyzes its functionality.
9:18 ⏱️ The expert uses OllyDumpExCU to dump the malware’s memory to a file for further analysis in Ghidra.
12:03 ⏱️ Dynamic analysis reveals the malware’s connection to a C2 server and its functionality as a credential harvester.
Key Insights
🧠 The malware injects into legitimate processes like command prompt and explorer.exe to avoid detection and further its malicious activities.
🧠 Analyzing the injected shellcode can provide insights into the malware’s functionality and potential vulnerabilities.
🧠 Dumping the malware’s memory and analyzing it in tools like Ghidra can reveal its inner workings and aid in understanding its behavior.
🧠 Dynamic analysis, such as monitoring network traffic, can provide valuable information about the malware’s communication with command and control servers.
🧠 The use of specific user agents and URLs in network traffic can be indicators of the malware’s identity and purpose.
🧠 Malware analysis requires a combination of static and dynamic analysis techniques to fully understand the malware’s behavior and mitigate its impact.
🧠 Ongoing research and analysis of malware samples can contribute to the development of effective detection and prevention strategies.
Transcript (AI generated from video):
00:00:01 hi everyone this is the second video in a two-part Series so if you haven't seen the first video I definitely recommend you check that out first now what I want to do is run this malware and try to see what processes spawn so that then I can begin to look at how I can go about debugging and getting some more information and I'm just going to go ahead and run it and straight away you can see that it does spawn a child process of Windows command prompt from the sisw 64 directory as opposed to the
00:00:28 system 32 directory which can be of interest then that process dies and now we only have the CMD process running so our initial point of compromise the executable that we'd be looking at is no longer running in memory and we only have the injected child process which is command prompt there is actually a spawned conhost process here but this is actually the executable that does a lot of the backend stuff that make the command prompt work so not something that is necessarily of interest for us to look into but we do see that
00:00:58 explorer.exe has also run so this is a little bit more interesting another process that's likely being injected into that we're going to have to try to debug and see what's happening and then the processors die all right no worries I'm going to go ahead and kill this cmd.exe process as it seems to still be running so there's a good chance oh never mind it's already exited the Ma has gone off it's run it's done what it wants to do and now it's no longer running on the system anymore so I'm going to go ahead and open up one of my
00:01:28 favorite debuggers the x64 debug and what I'm going to do is I'm going to look at launching the setup.exe and we're going to run it and by default this has got a breako on the entry point which is great what we can do is actually look at module loads so if we go over to our break points we can actually begin to enable stuff on module loads and in this case I actually still have a break point on a load of MP gear. dll I also added one for virtual protect and anti write virtual memory which are commonly used in process injection I'm
00:01:59 going to go head and run the malware the first thing we see is that we get a TS callback for the MS html. dll if we look at our running processes it's got a child process of setup.exe which is what we'd expect to see and this is something we're going to keep an eye on this is spawned under the runtime broker as opposed to explorer.exe but this is actually more so what happens when you launch something via the taskbar on Windows or at least Windows 10 let's run it and just see what we find so now
00:02:26 we've hit virtual protect now under the virtual protect you will notice if few things on the call stack here there is actually MP gear and if we go and look at our memory map it did actually load MP gear. dll so with this virtual protect call what we actually want to do is look down into this particular field here the reason why is cuz this will actually tell us what's being passed to that API call so in the first instance we have mshtml.dll and if we follow this in dump this is going to be the location in
00:02:57 memory that mshtml.dll is is actually residing and we can figure that out by following this in dump and then following this in the memory map and you can see the txt section of Ms html. dll is actually what is being targeted to change the protection rights here that are shown on the right hand side so what's actually going to happen is that the first parameter here so rcx is the address of what is being targeted the next parameter is the size that is the region which has to have its access protections
00:03:29 changed the third parameter is going to be what protections are going to be applied to this region of memory so what this means is that we have the text file in the mshtml.dll which is going to be Rewritten with the protection rights of 40 so 0x 40 in the constants is actually referring to page execute read write now this is pretty common whenever injection is occurring and what this means is that process in memory can be written to read from and executed from and so if we actually step over this now because
00:04:09 after virtual protect is called what that is going to do is proxy that to ENT protect virtual memory so this is actually what's going to do it in the kernel so now after that occurs you will actually notice that the protection on the txt section has now changeed to execute read write so let's continue so after we have it being set to the right permission we'll see a return we'll see some memory operations and you'll see that this now occurs in a loop as we step over so in the bottom here which is
00:04:40 the txt section of the msh HTML dll loaded into that process as we step over you will see that this hex value changes in the bottom and that is because of these operations that are overwriting this process in memory so now this is occurring to actually change what is contained within that dll so if we wanted to know what was going to be written to this process memory what we could do is we could actually look at how this flow is working as we go along it gets here and then it's going to jump and then it's going to occur again and
00:05:15 so what this means is that after that operation finishes it's going to then have the overwritten bytes into that process memory so I did create a breakpoint here and ran the process and what we actually have is now the underlying btes that have been changed in that process memory here now it is likely Shell Code so this does look like it's still possibly encrypted or you know just the Shell Code we can't make out any plain Tex strings which is a bit unfortunate but that's okay because we can continue along in our analysis at
00:05:48 this point you'll see lots of jumping operations not really a lot that's happening so this might be some control flow stuff but down here it does look like there might be a call to Virtual protect so changing the process memory again so this is a bit interesting let's create a breakpoint here now we're going to run the program and we hit this breakpoint beauty now we can actually see the protections that are going to be applied again the msh HTML dll in process memory and if we look at the memory map it is ew at the
00:06:17 moment so that's execute read right what's actually happening is it's now going to be changing that same segment of memory to the constant value of 20 now the constant value of 20 is Page execute read it's a bit interesting this is likely done to try to stop security products from identifying in memory that this has read write and execute permissions which is suspicious let's actually step over you will see that there is that call again to ENT protect virtual memory so we're going to step down make it to that and as soon as that
00:06:49 gets called so we'll go one step before we'll look at the memory map and it's execute read right now we are going to step over that call and now it's only execute and read so it's been changed and the permissions now are no longer with that suspicious read write execute now if we look at our running processes you'll see that this is still before any child process spawns so before we saw that command prompt spawn relatively quickly but now we're stepping over this quite slowly and we're seeing that a lot
00:07:17 of things happen actually before that process spawns now what we can do is actually try to break and see if we can detect that process being spawned so we want to probably look for create process W there might actually also be virtual Alec being used to allocate memory that is then going to be run in that process so I'm going to see if we can find that and there is there is actually a virtual Alec so we now have a break point on that now I'm also going to do create process W and there is there is actually a break
00:07:55 point now set on that as well this is good we're getting somewhere so we're going to run the program and now we can see that it has broken on create process W now we can look at the parameters that are applied to create process W so the main thing that we want to look at here is the rcx so if we follow that in dump we can see that this is actually windows sisw 64 cmd.exe so this is the application that is going to be started with the process there is actually another one which has the value of one
00:08:26 I'm not 100% on this but I believe that this is the flags that are aside to the process being started up so in the case of a flag one this is to denote that it is a debug process so let's actually step over and see what happens from here we have the process that's being set to run it hasn't run yet because it hasn't made a call to create process W we're just going to continue stepping over we can see that the CMD process has actually spawned as well and now that we've got a command prompt process
00:08:55 that's going to be injected into what I want to do is open up X3 32 debug and actually debug that process the reason why I'm opening up X32 debug instead of x64 debug is because that this is going to be a 32-bit process as indicated by the sisw 64 directory being used here that means it's a 32-bit process of the command prompt as opposed to a 64-bit process so let's open up X32 debug and I'm going to go file and attach you'll actually notice this is the only process that I have running on my system that is
00:09:26 a 32-bit process now that's a little bit interesting something to keep in mind there's going to be a lot of processors and executables that will be using 32-bit of versions of the software as opposed to 64-bit but you might want to keep an eye on child processors that are legitimate Windows utilities that are from the sisw 64 directory as opposed to these system 32 directory and that's often because the 32-bit processors are going to be used to make injection into those processors easier as opposed to
00:09:54 using a 64-bit binary let's attach to this process we can see that it's waiting for the thread to start you can actually see the threads that are running in this process and there only seems to be one at this point in time and if I hit pause nothing's going to happen because the thread is actually in a suspended state so the apis used in the injection technique here is the ENT map view of section so that's going to be to do with the memory map here and directly mapping that malicious code into that there is one location in
00:10:24 memory that actually still has execute read write permissions now if we go go ahead and follow that in our dump it doesn't seem to be anything there but these are just null bites so if we scroll down a bit more maybe we'll begin to uncover something that is sitting in memory and then we do we actually see this 55 8B and then a bunch of other hex values now going along we're looking into it and we can see probably nothing that is strings of Interest yet however this is likely all the Shell Code that's
00:11:00 going to be operating in the CMD process memory then we begin to see some strings so we can see failed to find fixed version info signature in ndl all right maybe that's nothing really of interest but then we can begin to see something very interesting so there is this debug object by the looks of things that says malware called resume thread now where else with this have come up this is in command prompt process right this is mapped to the command prompt process memory and this looks like something
00:11:30 that the developers had put in their malware to basically tell themselves hey the malware has now called resume thread so very interesting and it's likely we've found where this ma is sitting in the process memory and if we go down further we can see nquery virtual memory and then there does Look To Be Strings associated with debugging or reverse engineering so there's Ole debug Ida there's wind debug there's x64 debug immunity debugger we can see the assist internals strings as well and proom so
00:11:59 maybe maybe this is actually saying take a look at the process memory and if any of these exist just terminate don't actually do what you're supposed to do so at this point I really want to do some static analysis on the Shell Code that's going to be loaded into the command prompt process to understand what it's doing so I can rightclick this and go binary and save to a file now I'm going to save this on my desktop and I'm just going to call it malware bin now I can actually open this up in something
00:12:26 like gidra so I'm going to just drag in bin and now I have to determine what language this is going to be in now what we're actually looking at because of the way that the injection works is 64bit Shell Code inside of a 32-bit process so let's take a look at the language what we're actually looking for is 64bit code and we are just going to maybe look at a little endian and in visual studio so let's specify that's what this mabin is and we're going to import it and let gidr do its stuff remember that this is
00:12:58 Shell Code so it's not going to have anything like a PE header that allows us to easily understand what the executable is going to be doing and follow along with the analysis that being said we can still get a lot out of looking at the Shell Code okay so analysis is done very very quickly because there's not really much to go on now what we could actually do is look at the start here and we're assuming this is going to be the original operation codes that's going to occur from the Shell Code so we can
00:13:24 actually use D to disassemble this and begin to get instructions so you can see that on the right hand side now it begins to decompile those instructions and how this might look in our code so I'm going to do this a few times anything that's starting with a 55h here is a push to RBP so this is a bit interesting and something that we're going to want to decompile we're pushing RBP and you can see that maybe some code actually starts to come out of the Woodworks here so there is a jump to this lab down here
00:13:54 and maybe the flow is actually working properly interesting we begin to able to understand what this malware is doing a little bit more then as we scroll down it has decompiled quite a lot of the code now this 83h things begin to change again but I am going to attempt to just disassemble this as well and it looks like it went pretty well it doesn't seem to be any issues the flow seems to be working as well so that's good we do have 55 again so push RBP 55 again nice easy way to identify this and we have a
00:14:26 53 I'm not too sure what this instruction is but let's see if it decompiles and it's just pushing RBX so that's nice there's also jumps here that are occurring and it looks like now we've reached a stagnated point where disassembling this isn't giving us anything so it is quite possible that we've hit a string or some values here and by decompiling we may begin to experience some problems however we're going to make the presumption here and just see what pans out of the Woodworks we may not get this 100% right on where
00:14:59 we need to decompile but it is a process that can be taken with some trial and error Let's Go pass that string and go decompile there's a good chance that we've experienced some problems here because there are some values that are just throwing us off in general with our decompiling so that's not great if we scroll down though you'll see that there's other bits of code that has been able to be interpreted and are actually functioning as they should be so it's a bit interesting and within this it looks
00:15:28 like there are valid strings that have been pulled out so right down the bottom here you can see those strings of malware called resume thread debug object ntdll product version NTI query system o debug and etc etc so we can actually go ahead and convert the rest of these two strings as well so we do have from here the .exe all right so we can see the data here and we can actually change this you will notice above some of these strings are actually stored in asy so we do have asky anti query virtual memory but then
00:16:03 we also have Unicode for Oli debug so they're stored into different data variables maybe just to throw people off or for whatever reason so this would be a terminated Unicode there we go we got Unicode there as well so we're going to continue that with some of these other strings so we're going to change this to terminated Unicode Okay so we've got a lot of the strings now that have been brought back together this actually gives us a bit of an idea of of what the malware might be targeting and some of the apis that it
00:16:32 might be using there also seems to be the value 1337 now this could be a port that something is connecting back to or it could just be a little bit of an EEG to say leite we do actually see calls to what looks to be n WR file and NTI create file might be things that I want to break on in our X32 debug let's do a break point ENT right file let's actually continue this process now though to see if we can unravel anything else and here we have evidence that this is going to be writing to a file called 793
00:17:08 2092 so let's step along and see what this loader is actually doing now that it's started the command prompt process now we have the variable of that file name in the temp directory and then we have a call that's going to be occur to the MS HTML the code that's written into that dll's process memory again so let's actually open up and see if anything gets created in app data local temp and that number go across we do have 792 32 and we do see it so this has actually been written by the malware and this is
00:17:42 that setup.exe process still which in our case was the ab product and we have probably Shell Code so if we open this up this is being written to lots of stuff that probably doesn't make a lot of sense okay so let's continue at this at this point in time I believe we've seen the injector in action but we haven't actually seen the loader and the loader is going to be occurring from the cmd.exe process I don't think there's anything else that we need to be aware of in the setup.exe process that we have
00:18:14 here but on the off chance will continue going along seems to be a call to write file it could be off base here but it does look like the file that is being mentioned is whatever is referred to here this is the buffer that's going to be written so this is just creating a return carriage and a new line and the number of bytes there is two so that actually makes sense uh it doesn't look like it's doing a heck of a lot but maybe just appending to a existing file that's been created and that's it at
00:18:42 this point the debugging stops and we are at the end of the process so now we have to start looking into the loader we actually didn't see anything happen to this 792 file so this is of interest and you can see I've run this quite a few times during my debugging sessions cuz there's a number of files that are the exact same size and are going to likely have the exact same contents let's go ahead and we're going to start doing the same thing with this process understanding what it's doing and seems
00:19:12 like an exception was called so this ain't good this might actually be because of our debugging of this process and we might actually wind up in a situation where we can't continue we have these access violations and it seems like all hell is breaking loose I'm unfortunately in a situation now where both the processes have died what I think I might do is try that same attach process to a running process except in this case I'm not going to run it through a debugger until we get to that so I'm just going to attach
00:19:43 directly to the explorer.exe process and hopefully we will be able to see what happens so I've run the malware and I can see that the process spawns we do have cmd.exe spawning now I'm going to keep refreshing this until I can I mean I can see the CMD process but I really want to hit that Explorer process I'm just going to keep refreshing it there it is I'm just going to attach the process and we can see that there are a few errors as it begins to attach that's fine let's break this says the active thread is suspended so this has
00:20:20 been spawned in a suspended State now we can see it's running and we've got some errors trying to set a break point in the middle of it but we have actually got to a point where we can pause execution of the Explorer process so at this point we have to understand that the Explorer process has been injected using a different method to what we had before so in this case the Explorer process is essentially using a transaction now a transaction it can be thought of as essentially writing to a file but not actually writing to a file
00:20:52 so it's something that goes along in the background to say this data should be written to this file it's in a transaction action object and then from there it will say hey that transaction object let's take that and map it into the memory of this process so it's actually running in memory and also just roll it back roll back the transaction we actually don't want to write that to disk so it never actually writes to disk it off writes to dis I guess if you want to think about it that way then uses
00:21:20 that to write into the process memory it's a little bit more complicated and I'm not an expert in all this areas but this is a technique known as process Doppel ganging I'm not sure how this actually shows up when we're debugging it through something like x64 or X32 debug however I have noticed that in the memory map there is this get file name from handle failed in the image section of our particular process which to me is a bit interesting so if I follow along this in the dump okay it seems to be
00:21:50 null bites again but is this similar to what we saw before with shell code being written to the process well if I scroll down I can begin to see some strange bites and we also see this 5589 which is the exact same starting byit that we saw or it's pretty close at least so that 55 we actually remember that and if we look back on our gidra process at the start that was push RBP we might actually have another situation now where we have Shell Code in this process that is from here onwards and if we scroll down we can once again maybe
00:22:26 just begin to see if we see any strings that are of Interest we actually begin to see something a bit more interesting so there is this 3 three question mark and then it looks like true false null maybe some Unicode encoded strings here now as well what is this and what is this sitting in memory is this configuration of the malware in this region of memory we can actually see possibly a identifier for the malware so this bhg G Ki TCT Tac ib2 this is quite possibly some sort of license key or campaign identifier for whatever malware
00:23:07 is going to be loaded into memory there's also this gapy hyphen node.io and Triton body. fun which is quite possibly the command and control server so one of the things that I want to do is actually dump this memory but rather than just right-clicking and dumping the memory to a file I want to use a plugin known as Oly dump ex CU that will allow me to not only dump the process from memory but also build a fake PE header that allows me to have this instead of being Shell Code it will be an executable and this will allow easier
00:23:39 static analysis using tools such as gidra so I have all memory that I want to dump out and I want to use the re rebuild dump mode I'm going to use the dummy for the header source and choose a pe32 executable for the address I'm going to select the get file from handle module here that is specified and I'm also going to enable auto adjust image Base address in order to ensure there's no overlaps and rebuild data directory and from here I'm just going to hit dump and I'm going to be able to dump this to
00:24:13 a file and we're just going to call this ma dump now that we've got our ma dump executable I actually want to open it up in Ida this time just to show a different tool so I'm just going to choose the defaults and hit okay you can see straight away that the starting section has a bunch of nbes and that's CU we have that in the code that we saw and this is just going to be skipped over with essentially no operations for these byes straight away we can see that there are a lot of subf functions here we can also see a call to
00:24:47 some inbuilt functions as well if I'm to search through text in the code what I want to do is look for triton body as this is what we saw before and if I hit that it immediately takes me to the function that contains Triton body being used so this is a lot more interesting and we can actually see Triton body is going to be used before gappy node but these are going to be referenced in this function so we can actually go to the sub function hit X and then see all the calls to that sub function and it seems
00:25:21 like there is one call to that sub function as the output of an initial fun sub function now this is where things get fuzzy it looks like like there is a lot of control flow perhaps obfuscation that is going on here or a lot of different functions that can occur depending on a case that occurs in our check here this is pretty unreadable but this might actually be resolving particular apis so you can see that there are what looks to be some hex values maybe associated with a hash here but to make matters worse after this
00:25:56 call occurs there's this sub routine 879 E90 and if we examine that you can see on the left hand side the graph overview this has so much control flow obfuscation it makes it almost impossible to just look at and analyze what's happening you can see that the nodes are all over the place and the control flow has a number of jumps to hinder our analysis efforts at this point in time static analysis would need to have some sort of script run over to flatten out some of this control flow obfuscation that has occurred but I
00:26:35 think we'll jump over to Dynamic analysis to figure out what this is by running the malware and having fake net running it shows that there is a connection to Triton body. fun and it has the user agent Tesla browser 5.5 some more indicators and it is posting to C2 con I've gone ahead and open up up my packet capture with wire shark and I can see that the post request to C2 con is sending a license ID and this other variable in the j string as well as version 4.0 and this is likely a heartbeat or a check-in with the server
00:27:15 which gives us an idea of the license key tied to the person who has purchased this malware and also that this is actually a credential Harvester that is performing functions and a little bit of searching actually finds the the Tesla browser 5.5 user agent that we saw is actually known to be tied to Luma stealer which is what was the Assumption the naming Convention of C2 K as well as after that C2 sock are also known to be used by Luma stealer but that's it that's what I wanted to show you thanks so much for
00:27:50 sticking with me any thoughts feelings comments anything else in the comments section below and I will catch you next time [Music]
