Process Doppelganging by IDAT Loader for Over 18 Months

Thanks everyone for joining our talk. I'm Narend. I'm responsible for taking care of the advanced threat hunting program at Cyberproof. Um this Archa so a twist in the story u we'll be speaking on a different topic is not the one that was just announced just setting up the expectation right. So we'll be talking on different attack investigations that we have been performing uh across our telemetry and our customer base learning through where the EDS have failed multiple times and this purely on the infos stealer side of the uh you know payload that we have analyzed. So predominantly there was one particular loader by the name IDAT loader. It was also called as hijack loader by some of the competitors. We'll

be talking only about Idat loader campaigns that we saw active for close to about 18 to 24 months. Uh starting early 2023 to end of 2024. So short introduction of myself. I have been into the cyber security industry for about close to about 18 years. I worked with Microsoft Central 1 Semantic McAfee predominantly into malware analysis, reverse engineering, threat intelligence and threat hunting. Uh I also partner along with the MDR and the default team very closely. That's how I learned about the threat landscape, EDIA detection gaps and then supported their investigation throughout my career. Hello everyone. So myself Achenna, I'm senior threat hunter working along with Nanjen. So I have 10 plus years of experience across all cyber security

domains like I worked in vulnerability management, incident response, so threat hunting and as well I worked uh in Sentinel one Microsoft previously. So we will be going through uh the IDAT loader and as well as how info steelers have uh uh predominantly evolved using it. Okay. Uh so we actually take part in this monthly webinars happening at cyber proof. Uh it just happened yesterday. It's a recorded session. If you guys are interested to know about what did we investigate throughout that particular month, you can always join this session. Uh yesterday's one is recorded by the way. All right. Uh today's agenda is more about looking through the lens of a sock analyst and triaging different incidents

related to IDAT campaigns. Um we did find kind of a two waves of IDAT. So we just named it as variant one and variant 2. We studied the code level of this loaders. Um so we'll show you how the code blocks of variant one and variant 2 looked similar. uh we'll talk about the different apps that was I mean different campaigns that used listbate apps names uh at the delivery stage and then how did they constantly change the benign process into which they were performing process injection and that's just to evade uh your detection logics. Um then the entire research is primarily based on samples collected from virus total and through the knowledge that we

gained through different incidents that we worked in different companies. Just a disclaimer. So uh now we will see the highlevel overview like how we track the IDAT loader technique as well how info steelers they evolved over time. So back in August 2023 uh we uh add a case with respect to lumas dealer. So this one uh we saw uh the new technique uh named IDAT loader. So IDA loader what they were doing they were hiding the payload in the PNG file. So inside the PNG you can see a file like an image but inside that there was a payload and the purely the decryption decompression execution everything happened in the memory and not in the disk. Uh so this is what

happened and later uh in end of August we saw that rapid 7 they blocked about the same TTP whatever we saw in our environment. So they blocked the same TTP but this case uh there was not only Luma stealer there was other other steelers like steelc and secttop also we could see like more info steelers like vidar amad raccoon they started uh adopting the sideat loader technique and more like um even the mature malas like danabot remos they also started uh adopting for idat loader technique. So this is how like uh NJ said we were like tracking from our own research as well as from the outside sources. So then we came across on Feb 2027 like um sorry

2024 crowd strike they uh blogged about the IDA variant one. So in the IDAT variant one it's mostly like a modular framework. So within the framework they add like sys call based execution and multiple injection techniques also uh defense defense evasive logic. So these are the modules they were having and later in July 2024 we saw that AAST published um stating that IDAT loader is being used for a targeted attacks that like they were using it for a particular targeting a particular region or particular organization and uh there comes a more important technique which is process doppelganging which we will see in the next slides. So process doppelganging they were using legitimate files uh the normal files like

explorer.exe uh msbuild.exe but uh moving forward they were using uh unfamiliar files like more.com choice.com and we also saw a major shift in TTP like for initial access they were using fake human capture. So I think you you know about the fake human capture like if you see a page and what they usually do to identify if we are human or not they asked us to like copy paste a particular script they run a powershell script in our system and they download the payloads. So they were started using those initial access techniques and later we identifi like uh we uh saw across the other researcher groups where there was Ident variant 2. So we talked about IDA variant one

right? So there comes IDA variant 2. Here the config file was hidden inside the image pixel. So this how they were like changing their behavior. And why this is very serious because they are as we uh saw it's constantly being being like frequently updated and they can be reused across multiple malware families and even the threats they are like distributing across themsel and it's very easy to deploy because attackers no need to deploy like develop a malware they can just use this loader to uh uh what to fetch the payload dynamically so they can use it and also we see a strong integration with the initial access broker which means uh the access can be reused and

scalable. Also as I said the loader is a module. So we have an opportunity to add a additional codes like credential theft or you can uh download multiple malares or deply ransomware. So that that can be done with this loader and also they act as a packers or encrypters uh so that each time when you see this loader uh the version would be different. it won't be a same also uh there is a quick adoption so in previous slide we saw like uh so many info steelers they are using this u IDA loader technique because they are easy to deploy they are easy to adopt so uh uh that's being used by most of the info steelers and malware

and also most important importantly we don't see any ads or post in underground forums so uh it's not uh well known to uh the security groups as we don't have any uh information about this IDA loader since it was easy to deploy and it's been reused by multiple malware families it got popular and how it all started so just I I'll go through the kill chain uh so starting has shell they use the social engineering tactics so either by a malvertising page so uh victim would be like redirected to a malicious page where they would be uh downloading a fake uh chrome browser update or as I said the fake human capture. So these two methods they were following and the

file which we saw in our case was chrome setup.exe. So that file uh it was having multiple components like it had legitimate file malicious DLS PNG which is the main uh culprit and random extension files. So these were the uh components within those files and then the part the important part comes here is steography as you could see. So uh we talked about the payload was hidden inside the PNG file right. So that they named as a stegraphy. So what loader does it um check for idat chunk. So after the chunk there would be a data they extract that they decrypt using the exor and they prepare for execution. So that's how they do in the first step and later

what they do is they don't directly call the API. So usually we call the create process uh such kind of APIs right. So what they do is they uh uh follow API ashing. So at the runtime they resolve the API like ashes into a um like for example create process they won't call create process instead they call the particular ashes. So that's how they resolve during the runtime and uh how they uh load the malicious DL is they follow the DLL search order hijacking. So this as well uh what attackers are doing is they are placing their malicious DL in the application directory. So if the file is getting executed first it calls the DL from the

application directory so that it bypasses the monitoring. So they does that and the main uh technique they are using here is process doppelganging. So here uh comes a tricky part where the malware file will be executed. For this they are abusing NTFS transaction. So they create a file in a NTFS transaction and they write a malicious code create a process from it and then roll back the transaction. So while doing this what what happening is this the process is running not on the uh disk but in the memory. So the filebased detection or if you want to do any foreign analysis we won't be able to do that because file won't be available in the system. So

that's what they do uh by following the process doppelganging. And last the events plus direct uh sys call. So events gate um what they uh do is like they jump from 32-bit to 64-bit because most of the EDR works in 32-bit right so what they do is they they jump from 32 to 64 and they don't um like involve the APIs as I mentioned before they directly do the s calls like they use nallocate virtual memory n um uh write virtual memory so they use that kind of uh uh direct sys this call execution so that uh it bypasses EDR and we uh we find it very difficult to um actually uh um what say uh detect this loader

and okay so to summarize this is a highly modular uh loader technically speaking like you have a lot of steps that they have executed flawlessly we'll talk about that more and um so what I high level. If you see uh these are like some of those techniques that they have used, some of those modules that have actually helped deliver the info steeler at a later stage. But you had a loader, you had an injector, you had a killer module which is typical in any info steeler where it targets checks for running security processes or reverse engineering tools to identify if it's a researcher machine on which the malware is executing. If it finds any of those processes, it would

just terminate itself. It would it wouldn't, you know, progress further. Um, speaking of the DL search order hijacking, that's kind of typical across uh the e- crime and a group. So, that didn't stood out uh so difficult for us while analyzing. But the stemography part was very interesting because these IDA loader campaigns would drop an archive. We'll talk about that. Inside the archive you'll have a lot of component files including a PNG file. As uh Archer was saying the PNG file will not be dropped with PNG extension rather it would be of random name. So when the malware would pass through the PNG file, it would check for the PNG header. Then it would check for an ID that marker ID

A and only if that is met, the next four bytes would be the XR key that it would read in the memory and the following next chunk of code is the shell code that it gets uh you know decrypted and then the infection continues. So Zcaler did blog about that initially saying that these were the different malares that they s they saw getting distributed through IDA loader or hijack loader as they called it. All right. So now let's move on to the dynamic execution part. So how would you see when it comes to execution of this IDA loader malware campaigns. So if you run it and check it across process explorer you would see parent process

and child process getting launched. Typically in a case of an info stealer campaigns, there are two things that you should always focus on. It could be a self- injection or a remote injection technique. The malware would not randomly target any running processes and inject its code into it. It would have been programmed to target a specific process and if it is going to inject into that process, that's the remote code execution. Uh and if it's going to self- inject and terminate, that's a different uh uh process altogether. And you need to investigate from those angles. Now speaking of heaven's gate, this particular image if you see the setup.exe that you're seeing here is a 64-bit installer file and then

the moment you double click right you would see a command promp getting launched but it's getting launched from syso 64 folder. So that's a 32-bit executable running under the context of 64-bit and that should instantly give you a hint that am I dealing with heaven's gate technique typically used for bypassing uh and you can actually see here like if you hover the mouse on top of that to confirm that it's a 32-bit file in an IDA campaign the moment this cmd gets executed within seconds you would actually see explorer getting launched under that as a next process And if you're running defender or uh you know central one edrs you would see IOA or detection alert related to process

injection and you need to be very clear about that if the EDR or IOA is not alerting related to process doppelganging you probably have to speak with your detection engineering team to say that it's highly likely process doppelganging because when you see the API is getting monitored by EDR around this events that is a different set of API calls happening. and the API calls that happens around this execution of cmd where there is another injection that is happening that's related to process hollowing we'll talk about that in the coming slides so the API calls that gets called around these events are different for people who are not very familiar about process hollowing technique you will

have the benign process or the targeted process in a suspended state so the process gets suspended by the malware so when you're reverse engineering During uh the particular stage, you would see the flag set to an argument that corresponds to the suspended flag and then the malware would write write the code onto the area that it decides to write after nullifying or zeroing out that particular block. The malicious code gets added there and it would be resumed as a thread. So we'll talk about those API functions in the coming slide. So that's one way of process injection happening here and the process injection that happens into explored exe is a different one process doppelganging. So

the API names would be different as she said it happens in a transactional style and that's to protect the data integrity. So that's an additional check that attackers have performed and invested their time to ensure that post injection of its code into the benign process the parent process doesn't get corrupted and you know ends there it successfully made it run flawlessly so that post execution or injection the code into explore.exe the infostaler code starts executing. Now there's a lot of step-by-step diagram by the ways but so you have the infection starts from the download of an MSA file typically from an infected web page. Now when we started studying this campaign at the start I think around May

of 2023. Initially there was some kind of similarity to soish malware campaigns because soish is a malicious JavaScript file. I think it's tied to claw ransomware group and this particular infection is was first studied when uh soish group targeted garin in 2019 if I'm right so the infection look kind of same to soalish infection pattern where you have a compromised website um that uh you know leads to download of net support rat and so on but in this case it was an MSA file that got downloaded the MSA file once it get once it's being executed A lot of component files are dropped into a particular directory. You would see DL sideloading happening that malicious DL is the first stage where

the decryptor starts functioning. So you would see an attempt to bypass ADR through unhooking NLLL hook. There were two variants that we studied. The first variant is where we have seen the malware actually downloading a PNG file from a C2 uh domain. We'll show the reverse engine code of that. And the second variant is where we have seen the PNG file getting extracted from the resource section of the binary or it gets just dropped into the same directory just like that. This where like the key differentiating factors of the two variants and then you would see lot of XR decryption happening at multi-stages because the shell code gets written in different regions one after another by the decryptor getting

executed from the DL file. While reverse engineering you would also see that there's a step called DL stomping which is like only the text region of a DL gets modified and this encrypted data gets returned to that text session of the file and gets decrypted for the successive stages of kill chain. I can just imagine like all this has been happening flawlessly. That's a great job by the threat actors. What made it even difficult for us to stay out of this particular IDA campaign is that we had this point in the previous slide. We never saw an advertisement in the underground forum claiming like hey there's a new loader out there that's able to do these 10

steps which are done by IDAT loader as such because we could have got a detection strategy planned. Now DL stomping was done and then comes even more difficult part. You had an injector module and a loader module. Soon after this DL stomping happens, both injector and the uh loader module would perform the exact same steps. Both would perform Heaven's gate. Uh they would start creating random folders and random text names leveraging or calculating the environment variable and few other seeds like the time stamp and random number generation. and they would create random file names and folders and then you know the injector module would inject the code into cmd.exe exe the one that we saw in the process skill chain in the

previous slide. The loader would do kind of very similar part using the file that was dropped in the previous stage here under injector. This file gets utilized under the loader module and it is into it is from that file that explorer gets injected through process doppelganging leading to an info stealer launch. All this were happening flawlessly. I keep reiterating that because that's a phenomenal work by the threat actor group. We had never seen the uh malware file getting crashed over 100 plus incidents that we have investigated in the 18 months time. Now let's break down. So the decryptor model we'll talk about that. So throughout the execution of all the steps right malware authors have called

this anti- delay execution function or API function intentionally to slow down the execution. That's a careful step that they have taken which is great because they didn't want to rush and launch the infosiller at one go after all those steps. Now they did perform a constant check about presence of any of this researcher tools like processmon promon IDA OBG immunity debugger and so on just to confirm that the malware is not running inside a researcher machine that particular image is from zcaler. times but this is from our analysis. You would actually see the strings when you decrypt multiple times and land up in a memory region and then you know you check from the dump you

would see the strings API hashing a lot of malware do ransomwarees also use API hashing that's just to not let API function names be on a visible um string format when you do a static analysis just to evade detection so typically you would see API hashes uh related to functions from NDLL kernel 32DL and win NTI I win inet. DL in IT loaders getting hashed. So while you debug you would be able to find the actual API names associated with these DL names. This is a code from I think Vidar info stealer. One of those info steelers that used loader where after hashing you would see the necessary API functions being retrieved before the internet uh

outbound internet connection check is being performed. So it first checks for the presence of internet on your machine and then continues the that code was from I think X32 debugger and then you use a disassembler like IDA and you'll be able to do your analysis just rename based on your analysis and you'll be able to see you know the APF or the function that is responsible for API hashing and the API names that you would be able to resolve as you follow down the steps. This code here it gives you a hint of when the DL stomping start starts. You can see that the malware would make a copy of MSST ML.DL from sysvo folder.

From the dump you will also get the string related to cmd.exe and uh that's the exact starting stage when the heavens gate step would be performed at next stage. There's a decryption loop and then the shell code gets decrypted using this RTL dec uh decompress buffer. So that image that you see there was related to heaven's gate and this is the im uh code that you would actually see. So you want like in a 64-bit machine you want a 32-bit to get run you would actually see this kind of code there like 33 or 23 as reserved by I don't exactly remember the name is called reserved selector or so you want another process to run in a different operating

system model this really helps post this is when you'll have the direct sys called executed by the malware to evade EDR solutions So for people who don't know like so you have the user mode you have the kernel modes for any application that needs this API to be called it goes through user mode all the way to NOS kernel fetches the equivalent and goes back. So what the M so the EDRs typically for some of those EDRs perform inline hooking which means it modifies the first five bytes of the prologue with a jump instruction goes to the proxy function or the trampoline function of EDR. Once it EDR scans through the arguments of the function, it jumps back

to the very next address where this jump instruction is performed and the code flows. So what the malware does is performs a direct sys call all the way. Thereby it able to bypass some of those CDI solutions. Let's move on to the injector module. Injector module was the one that was responsible for injecting its code into cmd.exe exe through process hollowing and uh here are the list of API functions that was responsible for injecting the code post suspending the victim processes. So from a sock analyst or reverse engineering angle, the sock analyst would typically triage the event when there's an alert, right? What we were seeing was the EDS were missing and the sock analyst were on a blind spot.

So with our threat hunting query, they were able to execute in the cor in their environment and they were able to spot it. That's when we educated the socklessly saying that go beyond the EDR alerts. Look for these kind of traces or events study the process killchain tree check for injection techniques and if you are dealing with you know a target process like cmd.exe or in the next stage like explorer.exe making an outbound connection to a suspicious TLD associated with an infos stealer you can be very sure that you're dealing with IDAT loader or uh you know any other infos stealer. We'll talk about that. Let's move on to the loader module now. So you had the injector module. I told

you that you know calculating the environment variable and a lot of values from random seeds and timestamps. It was able to create random file names and random folder names. So the file would be taken by the loader at this stage. Uh and then it starts performing the process doppelganging to inject its code into explorer.exe. Now again like the previous slide as a threat hunter or investigator look for the API calls that it's going to deal with. These were those different API calls that you would deal with when it's process double ganging. You would see API calls related to the NTFS transaction model which is related to process double ganging. So some of this quick tip some of these API functions

would have transaction this is to protect the data integrity either you commit and write into the benign process or just roll back that is the plain message of process double ganging so there won't be any error of uh corrupting the files that's what you are seeing here and then the final payload gets executed through explorer.exe Xe speaking of those two variants the first variant is where we said that you know it's going to download the PNG file from the internet so before that it would load win http win httvl and ms vcrt into the memory and then it makes fake request to the legit domains where the png files are hosted downloads it starts loading it in the memory checks for the

IDA string checks the reads the key and starts decryting the shell code from the next level. This is that code that's responsible. So a request is being made. You would see some URLs. You can see it's ending with PNG file. It also checks for the presence of internet. An example of the PNG file that was had having the shell code stemography technique. So uh that was one of those images. You could see the blur image. Typically that's where the shell code resided. the code on the left side you can see there's a PNG header at the start and after a few bytes you'll see the ID that marker so the malware actually reads through the PNG file

checks for that marker the next four bytes is the key following that is the shell code that it decrypts in memory so nothing gets executed at the disk level that's the loop that you're seeing there where it starts decryting the code in the dump you can see the PNG file in memory being loaded and once it starts decryting you move to the next stage. This is just another view giving you the dump view how it looked in the debugger. In the second variant is what I saying like either the PNG file gets extracted from the resource section of the file or gets dropped along with the other component files in the same directory. Now the PNG file need not be with PNG

extension. It can be any random thing and that's what we have seen. All the files are with random extension ex except the legitimate .exe that loads the malicious DL through side loading at the initial stage. Rest everything was happening flawlessly. So the R file that you see there is the actual PNG file in variant 2. And uh for the variant where the PNG file was getting extracted from the R data session of the file, this is that code and that's the decryption function that starts post exe post extracting the code from the R data section of the binary. With all that this was very critical for us. So you had variant one variant two some level of the code

really matched. Some of those info steelers that used variant one at the time of our study was Hammed and Raccoon. Variant 2 was seen used by Luma and Vidar. This helped us to understand at least during a small time frame we were able to see that the same level of code was used by attackers uh across different info steelers and that gave us a fair understanding that there's some group out there sharing the code among themselves to launch different attacks against global organization. Not a big deal for us but from a customer standpoint you know they have invested a lot of money for EDIA solutions or other security solution we had to educate them to understand like

what are they dealing with what are we seeing and who are their enemies here is those four hashes that we reverse engineer samples are there in virus total they were not taken from incidents so reiterating the other point when the main installers were seen at the initial times, right? Initial days, they were using all these different random names, Webex, Defender, One Drive, Blu-ray, setup, Anyesk, all that it and users were actually tricked to either download uh you know some random binaries from different websites that impersonated legit pages. The best part was like the attackers kept changing the benign process that they initially started targeting to inject. Initially it was cmd then they moved into different

processes over the months. Back to the summarizations right. So what we started seeing from 23rd of August around the same time when rapid 7 also studied about IDAT loader we continue to see different info dealers adopting this IDAT loader and crow blogged about it. Aastas also blogged about it and then around July or August close to about after a year is when they started changing their targeted process which was very interesting for no reason. We are really not sure why it took so much time for them to just change the victim process name into their code but it was good but it is only after that the fake capture campaign started rising around the globe

but still we saw you know infos stealers getting dropped we're having some kind of similarity or tie-ups to the IDAT loadup around December of February 2025 so it has been there and after that time frame you still have all these fake caps campaigns running around but we we are not actually seeing IDAT loader campaigns in the recent months for sure but throughout this year it was a great time for us to study all those similarities that we highlighted John from uh Hunters was also talking about this in his YouTube video where he spoke about more.com I think he missed to speak about more.com but from the any run sandbox that was highlighted so we are in line with the security

community with whatever they are working on trying to protect the world from a threat hunter side. I'll just uh try to reiterate this. Look into injection related uh TTPs. It could be a pent testing happening or it's an infoscer happening. Either ways is always worth to let your customers know what they are dealing with. Check for gaps of your EDRs partner along with your detection engineering team to understand how you can fix that. Work with the sock team so that you can help them cover up the blind spot. a hunt for any additional IOC, HTTP is working closely with the thread hunting team. I told you about the info stealer that's getting launched post injection into explorer.exe, right?

There was a easy takeaway. All those domains that info stealers were connecting uh or making outbound connections, right? They were pretty tricky and it was very easy to spot. you had like dotshop cyu um some random or space something like that getting launched from explorer.exes context which is not uh the right thing. So it was a easy takeaway for us. So if you simply create a hunting query to look for outbound connections to such suspicious TLDDS and if there's a hit backtrack and when you backtrack if the source process is a browser I don't know what to call that it's okay but it's not okay I would say that there's an info stealer in your environment but if the

spawner process is an exe file and then you see injection and all that you can be very sure that you're dealing with an infostaler infection in the environment and then if you see some random files getting created into temp folder, app data folder along this timeline, you're dealing with an infoscaler incident for sure. With that, thank you so much. Thank you besides for having us here. If you have any questions, we'll be more than happy to answer.