Hunting unsigned DLLs to find APT

foreign

thank you for joining the session I'm very excited to be here by the way any threat hunters in the audience okay so by the end of this session all of you will be okay so um before starting to talk about some cyber stuff um by the way spoiler to our topic you can see here behind we're going to talk about some very easy way to find a very sophisticated threat actors but before going to talk about cyber stuff I will introduce myself so I couldn't think about more expected heading other than who am I so this is what we've got my name is Daniela chalev I'm a threat hunter in Palo Alto networks I'm 24 years old and I came

here from Israel I have been in the security industry for about six years started my way in the military service I was a security researcher in the Israeli Navy and then I came to Palo Alto addicted to avocado and to my dog Camila and in my daily job I do hunting across customers environments looking for known malware patterns doing research about apt groups and their evolvement over the years and if we find something malicious we do a deep dive investigation this can be resulted in some blog posts or some tweets on Twitter and today we're going to talk about some really cool research that we did over the past year so I'm sure that once all of you set in

your home in a nice evening drinking wine and thinking how can I catch a threat actor well who didn't I did so I came to give you um some tips so um we decided to conduct the research based on various attacks that we investigated over the past year where we found one thing that was mostly used by attackers and this is the loading of a dll so um while dll files are being used in a legitimate way all the times as a threat Hunter we are looking for something in a big data something that security products won't necessarily detect so we base our research on loading of a dll and why an attacker would rather to use

a dll than just execute a binary I guess that you know the answer but I will give a brief about this so a dll is a piece of code that is being loaded into another application which makes it more evasive and harder to detect as all malicious activity that is being performed by the dll is being initiated by the host process so um attackers usually use um two one of two main methods to load their malicious dll the first one will be dll hijacking and the second one is lol beans so what is dll hijacking this is a method to manipulate the dll search order of an application and to make it to load our malicious dll instead of a

legitimate one what is a dll search Order each application when it loads dll it has a specific order where it's going to look for the dll names in it if it can't find it in the first directory it will move forward to the next one if it can find it there it will move forward to the next one and Etc so attackers can manipulate the search order even um in the first directory which is the same directory that the application is being um executed from so all the attacker needs to do is just to rename its malicious dll with the name of a known and benign dll that is usually being loaded by an application

and this is happening because some applications will just load a dll by its name and it won't do additional checks so let's give an example how we can do it as an attacker if there's a known application that is called besides.exe It's supposed to load a dll that is called daniella.dll as an attacker I will call my malicious dll daniella.dll and I will place it together with besides.x in the same folder and it will be just loaded by besides.exe when it's going to be executed so the next method that we are basing our research on is the using usage of low beams low beams legitimate utilities of Windows in those examples we are going to talk about run dll 32 and Regis

vr32 they're being used all the time those are known applications to load dlls all we need to do is just execute for example run dll specify the dll path and if we want some function that will be our entry point and the dll will be just loaded into the memory of the Run dll process so our next point of the research is that we assuming that most case in most cases the dll won't be won't have a digital signature of course that digital signature won't inherently um point on something that is malicious or not but this is just a nice lead for investigation in most cases that we observed you will see um in the next

slides all dlls that we found were were not digitally signed and in the cases where attackers try to manipulate the digital signature most of security vendors can detect this so just in order to reduce Some Noise we were going to look on unsigned dlls and filter out the signed ones so the last point that we are going to base on is the path that the dll is loaded from usually legitimate applications are located in known folders such as C program data folder and see Windows system 32 for example but those folders require administrative privileges in order to write files into them so as an attacker attacker is not always um an admin on the host so usually they

will have to use some alternative way and we found that the most common paths that attackers choose to write their payloads into are the C program data folder and subfolders of the C user's folder so as you can imagine if we're going to look for all those points we will find a lot of results and we still have to dig into those results and understand what seems to be suspicious enough that we'll have to investigate it so in this stage um we were focusing on the frequency of executions and on some suspicious file paths suspicious expert functions and dll names and indeed we were able to find multiple malwares that were loaded unsigned dlls from unprivileged paths you can see here

um I don't know if you see the names I can okay so um it varies from a cyber crime malware such as info Steelers such as imotet um icedid a lot of banking Trojans and even um a sophisticated threat actors such as Mustang Panda apt group and the Lazarus group that we are going to talk about now so um I decided to give three examples of the previous slide we're going to talk about two apt groups that we were able to catch using um this logic and one new malware that is uh being recently spread so um let's start talking about the um Lazarus group okay so Lazarus group one of the malwares that we were able to catch

using this logic is in North Korean threat actor it um is responsible for major attacks over the years for example the Sony bridge in 2014 or the Bangladeshi Bank attack in 2016 and in this case in the scenario that we found it was targeting um the chemical sector companies the victim that we found was a gas company and Lazarus group are known for their usage of very sophisticated payloads they keep changing the payload for each victim and in this case we're going to talk about a supply chain attack and the usage of a lot of payloads and a lot of low beams so let's speak about the dll hijacking activity that we were able to find

we found an unsigned dll that is called mi.dll it was loaded by a signed binary which is called WSM Provost I hope that I'm pronouncing it correctly wsmprovhost.exim which is the winner and process both the dll and the binary were located in the subfolder of C program data folder which is not the correct location of the winner process the attacker didn't have the right privileges to write the malicious dll so he just copied the benign application and the malicious dll to the C program data folder so while the dll was loaded it executed a lot of reconnaissance commands and additional payloads you can see it in the screenshot behind you can see the the small circles but there are

just some reconnaissance commands okay so um we try to understand how this dll got into the disk in the first place and we found the supply supply chain attack that was originated in the installation of some old version of a software that is called initech basically the attack was delivered via a phishing email the victim received some fake job offer when it clicked on it some dll was injected into the initech software and dropped additional malware you can see here another execution chain of multi-stage malware that eventually also dropped our malicious mi.dll so um let's talk a bit about the mi.dll payload we found that the malicious dll that the unsigned dll was a compiled version of

an open source tool that is called bugtrap the backdrop project is available on GitHub and the attacker managed to change one of the expert functions of of the code he implanted their malicious code that was responsible for information stealing and for C2 connections as you can see in the screenshot from Ida because without any either screenshot it's not a cyber presentation um you can see here I don't know if you see her but um they're in the gray color you see a lot of the C2 domains that eventually additional malware were retrieved from so um oh and another thing I forgot to mention is that this dll wasn't recognized as malicious on any security vendor it seems to be legitimate except

from the fact that it has an invalid digital signature so um our next case is the raspberry Robin malware anyone familiar maybe with this name okay cool nice um so raspberry Robin was published quite recently although it was discovered in December 2021 it took six months to publish the first blog post about this because the dll that was found there was very very obfuscated it was very hard to do a reverse engineering on this payload so unlike the Lazarus group the raspberry Robin malware is uh Evol is being spread really really fast it seems to not Target some specific sector because we observed a lot of victims there um it showed up in the top of our

results as it was the most common malware that we were able to catch using our logic and let's go on some key points of the malware the first one is its infection Vector which is USB drive USB drive being connected to an infected host it contains a malicious lnk file a shortcut file that when clicked it executes an MSI exec command that eventually retrieves a malicious dll from a C2 server the malicious dll the payload is unique per each victim which makes it more harder to attribute this uh those payloads to raspberry rubbing as there will no be um two dlls with the same hash the next thing is the sophisticated C2 infrastructure each time a dll is being

downloaded from a C2 server it is going offline which means that I can't download the same payload twice and the last thing is the sophisticated payload itself as I mentioned it's as I mentioned it's really really obfuscated um it has a lot of layers of backing in it and the most interesting thing is that it makes researchers to think that this is just an adword when it's being executed on a virtual machine when there's a real payload that is staying packed and obfuscated while doing analysis on it so um speaking of our research how can we detect um loading of run the loading of the raspberry rubbing payload so raspberry Robin is being loaded using low beams

sometimes it will be run dll sometimes it will be Regis VR it varies between different attacks and as you can see in the bolded command um it is being loaded from a non-privileged path from C program data folder we observed also cases where it was loaded from some subfolders of C users folders and you can see a very obfuscated and weird name that already seems to be suspicious and requires some investigation and when being loaded it performs a process hollowing it injects itself into legitimate process such as notepad or dll host and then it initiates network connections to tour nodes it creates persistence by registry keys by schedule task and those are things that by the

way security products can detect but we can detect the loading of the dll even by the command line before it does some bad things so sorry wanted to give additional point about raspberry Robin except from the fact that it's very very obfuscated and the cool thing with the tricking security researchers into thinking that is an adverb the main motivation behind this malware is still unclear although some vendors tend to attribute this malware to the Russian evil Corp group but this is still unclear I think that we will hear about it more soon so our last case I know that you're all hungry to go to lunch so it's like the last uh last example we're going to talk

about Mustang Panda Chinese dread actor it started operating since 2017 and it targets multiple organizations in the US and um in Asia in our case we are talking about a victim from Singapore and Muslim Panda are known for the usage of plaguex rat mostly and poison ivy they use a lot of dll hijacking as we will see now I think that the the screenshots are a bit small but I will just describe what you can see here basically we found unsigned dll again which is called wscdll it was loaded by the legitimate Avast software again from an unprivileged path it was from the C program data folder and um as in the Lazarus case the attacker

didn't have the right privileges um so they wrote it to some weird path in C program data folder one thing worth mentioning about the Muslim Panda apt group is that they're using multiple benign applications for the dll hijacking activities we observed also additional cases um that there was dll hijacking to um Avira software to Adobe to ESET as well so um the attacker really likes antivirus products such as all of us um so let's talk a bit about the plug threat uh known rat being used a lot by Chinese threat actors has various capabilities such as information stealing key logging files modifications but the interesting thing here is that the loaded dll is just a loader the

actual payload is stored in an encrypted way in a file with a DOT extension it you can see like the file paths there I don't know if it's clear enough but the main point here is that when investigating plug executivity or Mustang Panda activity we should expect to see the creation of three files not to um of a B9 application of a loader dll and of an encrypted payload sometimes it will be in forms of other file extensions not only that file so it can vary in different cases and to sum up the activity of Mustang panda in this case we observed after the loading of the dll um registry persistence in run Keys it

was spreaded by USB devices we observed a lot of infected hosts here and uh finally we observed files exfiltrations multiple documents were delivered to C2 servers in Hong Kong and when being copied they were renamed with a base64 encoded name so finished with the examples let's talk a bit about how you can catch a threat actor using our really simple logic so um if getting back to unprivileged paths we were talking about this the entire session so um not too much to elaborate here just really um recommended to look at the path that the dll or the file is being loaded from of course it doesn't indicate on something malicious but it is a good lead for investigation

the next thing that we didn't have a chance to talk about is a file entropy I will explain for those um who are not familiar with this term file entropy is a way to measure the randomness of the data in a file so when a file is being packed for example the randomness is becomes becomes smaller so um the entropy of the file becomes bigger so if we see a large entropy of a file this is some something that we can calculate um we may assume that it might be packed not all cases will be malicious of course because for example archived files also have a large entropy and fun fact sometimes software developers like to run Packers on their

on their binaries so no one can do reverse engineering for that and to see the source code so um large entropy suspicious but not inherently malicious and the last thing that I think is the most important one is the frequency of executions as a good Hunter we should know our Baseline of the environment we should know what is usually being executed in an environment and once we know what's so common in our environment and what's the regular executions it will be way easier for us to find the suspicious ones um and to find new malware such as in those cases thank you very much [Applause] foreign