
for on the next presenter Alina. There we go. And uh while you set up I'll quickly do the introduction. So Alina is one of our students here at well technically past student but let's say one of your one of our students here at uh at Norov and planning to graduate now in in June uh with a bachelor's degree in cyber security. Now during her final year of study, she worked part-time as a security analyst uh in a sock and she will transition to a full-time role at Orange Cyber Defense. So very very interesting indeed. Um so she's going to talk to us about ransomware detection based on comparative hybridized analysis. Fantastic. Good luck. So um yes uh thank you for the
introduction. Um my bachelor project was uh really exciting because I got to um investigate how we could uh write more uh robust detections for one of the most uh sort of uh dangerous threats in the cyber security landscape now which is ransomware. So uh ransomware is when uh the attacker will encrypt the files on the computer and then demand a ransom for the decryption key to restore the files. And this is serious enough in itself. But what we have also seen has happened is that uh they are doing double extortion attacks which before they decrypt the files encrypt the files they are extracting the files and then if the victim doesn't pay they are also
blackmailing the victim to pay even more ransom to not publish the files. And this can be really serious because sometimes it's intellectual property. It can be personal information. So um this increases the pressure even more. And to make it even worse, uh we have seen ransomware as a service being deployed sort of as a business model uh with organized crime where even non-technical threat actors could launch sophisticated ransomware attacks uh because they can lease infrastructure or get others to write the ransware for them and then as a uh payment for this the uh the authors or sort of providers of the ransomware as a service get the percentage for example of the ransom demand. Um and uh what can be seen is that uh
ransomware has just increased in frequency. So uh these are numbers pulled from um leak sites that Palatoto has been monitoring. So of course this can be a bit hard to uh get a perfect u estimate of. Uh but um by monitoring these sites over time you can at least see a very big increase. And in 2024 uh around 6,000 posts remain to these leak sites and this indicates 6,000 attacks. Um and behind each of these attacks uh there is a ransom demand which has also increased. Uh and in 2024 uh for each of these six attacks it was a ransom demand of $2 million uh or actually a ransom payment and that is money going straight to organized
crime. Um so although we are trying to stop ransomware we are not successful because it's still a really big problem and what we want to do is to because ransomware is malware. It is a file which ends up on the system and we want to stop it before it executes and encrypts the files on the system. So we can detect it as we do with other malware um by using a very common way to do this is still signature based detection. Uh but the really big problem with this um is that it's very easy to change because as illustrated you could use other signatures as well. But a very common way to identify a malicious file
is the file hash. Uh but as you can see here it's very easy to just change this. If you just alter one character the entire hash changes and the hash might not be known anymore and it might be allowed to run on the system because it's not less malicious. And uh the threat actors are also aware of this. So altered versions of the ransomware or new versions of the ransomware are often able to evade detection. So what I wanted to do in my bachelor project was to try to find a better way to write detections which is not so linked to one file only. So um I compared two uh widely different ransomware families. Uh
fus is deployed as a ransomware as a service and has been around for around 5 years. So it's a bit older and black suit is newer and it's also the name of a group. So they are more um targeting their own victims sort of not as friends as a service. Uh but they're by the difference uh which you're going to see later on also. Uh so the idea was that if two completely diverse families have something in common which both makes them ransomware then this should be applicable to even new types of ransomware or other types of ransomware. So it's not tied to only what a signature which might detect fobos. So that was the idea behind the project. Uh
and what I did was uh analyze it with a hybridized framework and so it contained static analysis which is everything you can find about the file before it has executed and it was also dynamic analysis which is all the observations while the file is running. uh I also did a separate network analysis for the network traffic that was generated uh during the dynamic analysis and also forensic analysis for all everything left on the system after the file has executed and I also included my attack mapping which I'm not going to go into that we have had a nice introduction to that now uh but it's included in the complete report I wrote uh and after I
done this um comparison I wanted to write then a y rule uh based on my findings so Uh in practice I uh ran the two samples in four online sandboxes. Um so this is what it looked like. It's it was a bit fun to see how it would be like without danger uh what it would look like to be infected with ransomware. Uh so this is what it looks like. Uh if you are infected with black suit ransomware. Um and these sandboxes generate uh it's not like a hardware based system. It's online sandboxes. They're free. there you could just upload the files to it and run it and uh you get a detailed report and uh if you know where you're
looking you get all the registry key changes everything is logged and you can also uh download all the files you need for for example pcaps for network traffic so everything you need as it as if you were analyzing on a hardware system so they're pretty good um and I made some interesting observations for both of them because as I said they were very different So uh I'm only going to highlight uh the most important things or what I found most interesting. So Fubus would use a pretty common I would say persistent mechanism. It will write itself to the startup registry key which means that every time the computer starts it will run certain programs automatically and then in this
case it would run fusable transware whenever you start a computer which is not good and then uh it would also uh drop another executable immediately after it started running on the system. Uh, and this was a bit interesting because I analyzed this file um separately and it seems it's been um dropped by over 9,000 other malware files. Uh, so it's a reuse of code. So what this file will do is to it's um a beaconing uh function. So what it does, it's telling the attacker that the victim uh victim machine has been successfully infected. So it will uh connect to that domain and download a tiny file over and over again just to let the attacker know that the
ransomware has worked uh and then it will delete itself. Um but uh it's interesting to see that it was shared by so many and it wasn't al only ransomware it was like all types malware. So this is t uh clearly something that's used by others but sadly not black suit though. So uh blexit uh was very different. Uh first of all uh it was hard to make it run in the sandbox. I couldn't make it execute. I uploaded it and I even tried to live interact with it and double click and tried like so many things but um it needs a um command line argument to run and if you don't have this command line argument it won't do
anything. The sandbox just said ah it's a benign file and I was like it's not. I know it's not. It's supposed to destroy the computer but it didn't. But when you provide ID or name and then a 32-bit uh number uh it will delete backup display note encryption and also perform lateral movements uh with SMB. Uh but this ID is also used um it is can be considered sort of a sandbox evasion because if you were automatically just uploading it to a sandbox for example as an ADR could do then it would say it's a den file because you don't have that it doesn't do anything. Um and the idea is also included in the ransom notes
itself. Um so uh that was a bit special but uh they had something in common even though they were very different. So uh during as I said I did it systematically. So with a static uh analysis I found out that they both have high entropy and this is um indicating that the file is packed or encrypted or other otherwise obiscated. Um and also I found some similar uh imports in the PE header which is the mandatory metadata for all Windows executables. It's telling uh what functions that program is going to need from the operating system. Uh so it can tell uh a lot about what the file is going to do. Um and I found some
something that's common for basically every Windows executables because it's program. But I also found some uh common um or suspicious detection evation methods which I'm going to come back to. Uh during the dynamic analysis as you saw it was very different but they had one command line that they both performed uh which is um the one you see here. It deletes the shadow copies on the machine which is a sort of it could be used as a backup function. If uh the files were encrypted you could restore from snapshots created automatically by Windows. But if you run this you cannot do that anymore because they don't exist. So this is to inhibit system recovery and also increase the impact of
the attack so that the victim has to pay the ransom and cannot uh restore the files otherwise. Uh during the network analysis um as uh you also saw they uh fulus used the beacon and uh black suit did not. But what they both did was using the deprecated net bias protocol for some um discovery purpose uh and also for um what I believe uh is um lateral movement and focus even tried to execute code remotely because you could also do this with this uh protocol which is also why it's deprecated because it has some security issues um but uh in common they both sent uh netwise traffic over port 137 um And during the forensic findings, I
went through all the registry keys that was queried and altered uh because this contains a lot of important all the functions no uh settings on the machine. Um and they queried some suspicious uh registry keys. For example, uh the ones you see up here is used to ensure that all files for example to be able to run they need to be signed but the ranser is not signed. So um it needed to check this register keys and it also set it to uh allow untrusted traffic uh and also it performed a common system discovery uh by checking the language of the of the country language of the computer it had infected and this is common because
the attacker doesn't necessarily want to infect um the country where they're from themselves. Um, and after I gathered all of this, I wanted to choose something to write my detection rule on because now I know that this was in common for both the families. Uh, but I needed to choose the best one to write a detection that could actually be used in practice. Uh, and I decided to use yada because it's uh widely used. It's uh quite easy to write uh write in it, which you'll see later. uh and I used the pyramid of pain to try to choose which um uh IC's in then in the cases of compromise I was going to use in my rule and I also created some
evaluation criteria to uh try to um make a good rule as possible which you can see there. So uh what I chose to do was to use the static features I found because this is the early stage uh possible that you can detect the ransomware because the file hasn't done anything yet. It's just and not executed. It's just there. So no harm done uh yet. So I made it to trigger on the imports from the P header uh which is sleep wait for single object and wait for multiple object. And these are a sample activation technique uh that is used to delay the execution of the program. so that when you upload it to the sandbox, it won't do anything. It
will wait until the sandbox times out and then the sandbox says it's a banana file. But when it's on the on a real life system, you have infinite time at least more than the sandbox has and then it does all the malicious stuff. So just the presence of this I found suspicious and made it to trigger and I also included the high entropy and some other things to make it a bit less prone to false positives. Uh so a rule can be really simple. It doesn't have to be long. Um so what you do here is you just make it you can um use the PE module which then then you can make it trigger all things in the PE
header of the file. So this one just checks it will flag the file if it if the kernel 32 DL uh is loaded with the function sleep then it will trigger the file. So it's pretty simple. So my rule included a bit more stuff but it's still very easy. You can write it in just a text editor. Uh and you can use it for periodic scans if you make um you can make that yourself. Uh it's also supported by a lot of um edrs actually. Um and you could also just scan uh files or a folder uh if you found it suspicious or want to check if it's anything malicious in it. So um yeah, the project as a whole was just
trying to find a new way to sort of choose what indicators of compromise you're going to do. And it's also I think it's a very realistic practical implementation of it because when you have new um malware, you need to analyze it to write the detection of it. But this is sort of a way to do it a bit more robust than just taking the hash or taking something only to that file but uh which could actually be applicable to several files or to um even older versions of the ransomware or new they are constantly developing uh the ransomware families over time. So um yeah and if you're interested to see the rule as a whole or uh also more
practical implementations of the rules or framework uh I have put a lot of stuff on GitHub for it and um if any questions or comments or anything you could send me on LinkedIn but