Malware Analysis In 5+ Hours - Full Course - Learn Practical Malware Analysis!

hello and welcome to practical malware analysis and triage my name is matt kiley i go by husky hacks and i will be your instructor for this course on the art and science of malware analysis so let's do a quick who am i when it comes down to it i am a guy that tries to learn something every single day as i said my real name is matt kiley and i go by husky hacks online i am a cat dad that cat that you see in the middle there that little black and white tuxedo guy his name is cosmo you'll actually be seeing him a little bit more during this course and he's a black and white tuxedo cat and i love him very much i am also a mountaineer i have summited mount kilimanjaro like you can see up in the upper right hand corner i've done much of the new hampshire white mountain ranges i was through hiking the appalachian trail i got pretty far and then had to turn back because of the covet 19 outbreak but i do plan on getting back out there and finishing it someday i'm also a marine corps veteran and i was staff at mit lincoln laboratory in their space systems and research division as their lead cyber security analyst now some of my education credentials i have a bachelor of science in i.t from northeastern university in boston massachusetts and a graduate certificate in cyber security from the rochester institute of technology i was also previously a red team operator at a large financial institution and now i write and produce content professionally on twitter i'm at husky hacksmk and hey feel free to give me a follow or just send me memes if you want now let's do a brief overview of this course this course is a purely practical introduction to the field of malware analysis triage and light reverse engineering this course has an emphasis on malware that is common to the windows operating system and the malware binary samples that have been written for this course emulate real-world malware ttps some of the most common things that you'll see hitting endpoints in your organization are going to be emulated in these malware binaries you're going to learn the state of the art of malware analysis with a focus on techniques and methodologies first and tools second because tools always come and go and there are always improvements being made to tools but the methodologies and techniques generally remain the same now one thing i'm most proud of is the fact that this is a lab centered course now there are 20 plus malware specimens in the lab repository that was built for this course and they're yours to poke them produm slice them splice them dissect them inspect them to your heart's content and the vast majority of them were written custom by me to reinforce the learning concepts of this course and to be safe for analysis you're also going to learn how to build a malware analysis lab from the ground up and how to handle malware safely you'll learn how to proceed through an analysis methodology to extract key insights out of these samples and along with real world ttps you're going to learn the latest trends in malware and tradecraft we have malware samples written in many different types of languages like go and nim and c-sharp we have different types of malware like ransomware process injectors we have c2 agents we have malicious documents we have malware delivered via vbs and powershell and much much more there is tons to explore in this course and all of it mirrors the real world and what's going on with malware today and finally and maybe most importantly this course covers report writing and signature writing so that we can publish well-written reports to tell the world what we saw now let's briefly cover the topics of this course from a high level we will start with safety always setting up a lab and malware handling in which you will learn the safe practices and build good habits of malware handling we will then move to learning the four foundationals of malware analysis basic static analysis basic dynamic analysis we will then have a challenge binary advanced static analysis advanced dynamic analysis and then we will have another challenge binary and then after we have learned the foundational phases we will move out to more specialty classes of malware this will include phishing malware like microsoft word remote template injection and microsoft excel macros we will look at shell code analysis we will also look at scripted malware delivery including powershell and vbs we will then move on to c-sharp assemblies in which we will decompile and analyze the near source code of a c-sharp assembly we will then analyze malware written in go and we will take a look at android malware in the mobile applications section finally for a penultimate course capstone we will look at the boss fights in which you will analyze a real world malware specimen after the penultimate challenge we will look at automating the process with jupiter notebooks and malware sandboxes and then we will talk about writing yara rules finally we will talk about writing clear and concise triage reports and organizing our notes to submit for publication and then we will have the course capstone which i will leave as a surprise until we get there and finally we will wrap up with a course conclusion and some further readings now i've got to say this from the beginning and i want to set the tone right here this course presents risky activities by nature but that's okay your safety and as an instructor i'm not just saying this i do believe this your safety is extremely important to me so safe malware handling procedures are taught from the very beginning of this course and it is critical that you follow them at all times when you're handling malware it never hurts to go back and look through your configs and make sure that your configurations are all okay and that your host and operating system are not going to be at risk while we're learning these skills and finally i just want to say thank you sincerely this is an incredible thing to be able to put together and give to the community and i just want to thank you for purchasing the course i hope that anyone regardless of your skill level can leave this course having learned something and as an aside if you'd like to email me my email is right there or you can dm me on twitter i love hearing from students i love answering questions so please don't don't hesitate reach out if you'd like and now let's move on to the next section here we're going to talk a little bit about the course discord and where you can find support and talk to me directly on discord so we'll see you over in that section all right my friends let's get this party started in this video we're going to be going over how to install the hypervisor that we'll be using in this course hypervisor is very important for malware safety because it allows you to detonate malware in a safe environment without risking your physical operating system very very important now the hypervisor we'll be using for this course is oracle virtualbox and i chose oracle virtualbox for a couple reasons one it's free it's open source it's very very easy to use but more importantly it allows you to take and fall back to snapshots and that's going to be very important when we start detonating malware in the environment so what we're going to do is google virtualbox and you can say oracle as well and download and go ahead and google that and one of the first links here is going to be the one that we want to go to we want to go to virtualbox.org and the downloads section you can go ahead and click on that it's going to bring you to this page with the downloads for different hosts and for this video i'm working on a completely stock brand new windows 10 install so i'm going to install it for windows but of course feel free to install this on the operating system that you own and i will throw some links in the references for how to install virtualbox on the different host operating systems but in any case we're going to download the virtualbox installer it's pretty quick and once it does a quick little virus scan we can throw this right onto the desktop right here double click on this installer executable to run it and we're effectively going to leave all of the default settings through this installation and you can change this to however you desire but i'm going to leave it to the defaults and there will be a uac prompt right here you can select yes there will be a few times when this asks hey do you want to trust anything that oracle decides to install on your computer i'll leave it up to you to say that i'm going to go ahead and say yes you don't have to of course and that's why it's asking but it will run the installer and when you see this right here you will click finish and you can start oracle virtualbox right there and here we go if you're seeing this window you have installed it correctly and this is now available to you to build the virtual machines that we'll use in this course and in the next video we're going to grab those virtual machine images we're going to build them and we're going to get going on building our lab out so meet me in the next video and i'll see you over there alright everyone so i have moved back to my physical host you can see the changed background with this gorgeous gorgeous view here and what we're going to do is install the first operating system that we need for this course and that's going to be a windows 10 operating system and it's important to have a windows 10 operating system because a lot of the malware not all of it but a lot of the malware we'll be working with in this course is designed specifically for windows 10 and that's actually something that's pretty common out in the real world too most people use windows 10 and therefore most malware is designed for windows operating systems so what we'll need to do is go find the windows evaluation copy for windows 10 and one of these first links right here try windows 10 enterprise on the microsoft evaluation center at microsoft.com so you know it's legit it'll bring you over here and we can select our iso for when the windows 10 enterprise edition we select our enterprise iso and we can hit continue now it will ask you for some information here i'm not going to tell you you need to actually put in your real information so i'm asd asd i work at asd llc one person in the company i'm in the press my email is asd asd.com my phone number is one one one one one one one three three and i live in antarctica there it is all right great and i don't need any additional tips on this i can hit continue it will ask you what type of architecture you want for this windows operating system we will select 64-bit that's very important that we select the 64-bit version of this operating system and go ahead and select your language i'm going to select english and with all of these settings selected you can go ahead and click download this is a pretty big file it's about five gigs so this may take a while depending on your speed of internet so we'll go ahead and fast forward to the part where this is completely downloaded i'll see you in a second and here we go we have a downloaded iso i hope you enjoyed that slight break i myself treated myself to a nice shot of espresso and uh it was very good but we're back now we have our iso downloaded what i want you to do is find a place on your operating system where you can keep your virtual machines and if you look at what i have i have my virtual machines located in my documents section on my physical host and here you can see all of the virtual machines that i've put together now i've made a pmat section in the virtual machines directory that i can store all of my vms and my isos and so what you can do is create a section on your hard drive where you can keep these and just copy that right into that directory and this will just help us keep organized for when we're building our virtual machines now we will set up our windows operating system what we need to do is go to the new button right here in the tools section and we're going to set up a windows 10 64-bit operating system now for the machine folder it will give you this uh default location but you can also set it to that area that we just set up in documents virtual machines pmat if you so desire but wherever you put it just make sure that you keep track of it so you know where it is and we're going to call this pmat dash flare vm f-l-a-r-e-v-m and we'll talk about what that means here in a second but for right now we'll hit next we can keep our ram size to the default two gigs of ram should be fine for this install and we'll create a virtual hard disk now of type vdi virtualbox disk image and you can hit next dynamically allocated is fine you can click next and for the storage amount you can leave this to the default and you can make sure that it goes into the pmat flare vm section and we hit create now we have a placeholder virtual machine and if we start this up virtualbox is going to say hey we want to start this vm but we don't know what to do with it we don't know what image to use and so what we need for this is we're going to go to add and we can go to our pmats section so navigate to documents we'll go to virtual machines if i do date modified i'll go to pmat and we can select this iso that we've just downloaded and hit open now if there are any other isos here we can go ahead and ignore those so just click the virtual machine iso that we downloaded and click choose and we hit start and virtualbox is going to do its thing it's going to initialize the install if you do see this windows loading screen right here you have correctly set this up and what we now need to do is install our windows 10 iso as a virtual machine you can select your settings that you want and click install now and just let this run for a little while now you'll see this you can click i accept the license terms go ahead and read those if you need something to help you fall asleep but otherwise you'll select custom install you will click new on the drive 0 on allocated space and click apply leaving all of these to the default you can click ok at this prompt it will create additional partitions here and that's fine you'll click next and this will install the virtual machine operating system and this may take a little while so i will cut to the part where we pick up after the install has completed so i'll see you in a bit now after the install is complete you'll see this it will restart here in a couple seconds and virtualbox will boot up again it will skip by the boot from cd or dvd and go right to the iso boot all right now we are at the windows installation portion of the install here we'll hit yes to whichever your area is you can select your keyboard i select us we don't need to add a second keyboard layout that's fine now this is going to set up just some run-of-the-mill windows installation features we just have to click through more or less on these because we're not really setting this up to be a host that we're going to use every day we're setting this up just to be a lab environment now at this point it's going to ask you if you want to sign in with microsoft you really don't need to do that you can just do a domain join here and you're going to say uh whatever user you want for this and i'm going to say husky we'll click next uh super memorable password will be password and confirm password security question uh one will be name of the city i was born in and that's of course asd security question two is first pet's name and that's going to be asd and security question three oldest cousin is bob okay now for this one gotta love microsoft here go ahead and select no for all of these settings and we'll go ahead and say not now with cortana we don't necessarily need cortana for our purposes once you pass through that section of the install it will give you the little we're getting everything ready for you you just have to give it another minute here and it should boot to the desktop all right and if you see this awesome gorgeous windows background you have successfully booted to the desktop but wait there's one more thing that we got to do here and you're probably wondering am i going to have to do the whole course in this tiny little virtual machine window and the answer to that is only if you want to otherwise no what you can do is go up to devices here and insert guest edition cd image and this will load in a cd drive to the virtual machine you just got to wait a second if you go down to your file explorer right here and go to this pc you'll be able to see it here virtual uh box guest additions right here go ahead and open this up and among all of the files that are available here we do have the vbox windows editions amd64 otherwise known as 64-bit we'll go ahead and double-click on this to install our virtual machine tools if you get the uac prompt you can go ahead and click yes and we're just going to leave all of these to the default settings and click install so just click through those click install again oracle's gonna ask you do you wanna trust everything that we install here i will say yes you don't have to and you're gonna see some funky action on the screen and you're gonna see this right here reboot now all you got to do is reboot the guest operating system and then when you restart the guest operating system the vm tools will boot up as a service so go ahead and log in to your account here and it may just take a second to boot up you might see a cmd.exe window pop up right here for a second and then if you click minimize and click maximize you now should have a better screen resolution and why don't we go ahead and just get rid of these little bubbles right here and you should have your base installed windows 10 operating system now we're going to do something very very important i want you to go up to here and we're going to be doing this a lot in this course so it's very important you get this right if you go up to machine and go down to take snapshot we're going to call this base not vase base install your base install snapshot is going to be very important if anything else messes up through the duration of this course you can always revert back to your base install snapshot and that's it for our base windows install next up we're going to show you how to install remnux which is our linux operating system we'll be using in this course and then after that we'll come back to our windows operating system and install all of the tools that we're going to need to actually do the work of the course so meet me in the next video and we'll talk there all right now in the last video we set up our windows 10 base operating system and if we're still here all we need to do right now is go click on machine and click pause and that will effectively suspend our virtual machine we don't need to worry about this for a little bit next up we need to find something called remnux which is a linux distribution that is built specifically for malware analysis and reverse engineering so if we go to trusty old google we're going to type in remnux r-e-m-n-u-x and we'll take a look here at remnucks.org we can open this up and this is the page to download the distro of remnux we're going to go ahead and click download and if we're looking at the virtualbox ova we're going to download the ova from box which is the primary distro download site and it says we can't preview this because it's too big that's okay you go ahead and click download now again this is about five gigs so this is going to take a little while so go grab yourself a nice beverage or maybe a snack or something and i'll see you in a little bit all right it looks like remnucks has finished downloading now we're going to make a new directory and we'll call this pmat remnucks open up that directory and we will drag this right into this new directory that we just created now we can actually go ahead and open with and you'll see the virtualbox manager here you may have some other hypervisors installed but don't worry about those for now you can actually just open this up right in virtualbox and it's going to bring you to the import section for this vm image we don't have to install this from base image like windows 10 this is a pre-built installation ready to go all you need to do is import it so we can actually rename this and we're going to call this pmats remnux and we can go ahead and click import and this might just take a second now after the install we'll have our pmat remnucks virtual machine guest operating system here and we can go ahead and click start and fire this bad boy up and it will go through the boot process and bring us to the home screen this should be pretty quick this is a pretty lightweight operating system so it's it's very snappy now it should boot us right into the desktop and open up a terminal for us which is quite nice so you can kind of make this smaller again we've got a very tiny screen here so we can get rid of these bubbles here now what we want to do is sudo make deer we're going to go to media and we're going to go to cd-rom this is going to be an empty directory that will house the mounted cd that we're about to put into the operating system and we want to do a sudo mount dev cd-rom and then we need a place for this which is the place we just made media cd rom and it will say device right protected mounting read only that's totally fine so we will go to media cd-rom and ls and we should have a whole bunch of scripts here so what we want to do is punch up to the root user so sudo-s it won't prompt you for a password at this point and what we'll do is dot slash autorun.sh and this will bring up our installation menu and this should install all of the tools that we're going to need to make this operating system a little bit easier to work in inside of the hypervisor and this will take a second so i will cut to when this is done all right and if you see press return to close this window you can go ahead and hit enter and now all we need to do is reboot and this will bring us back out and virtualbox will do its thing it will load up the guest operating system and we'll just wait to come back and we should pop right back into our remnux operating system but this time we'll have a nice big operating system desktop environment to be able to work in isn't that nice look at that now if this doesn't happen if this is still in a tiny little box for you all you got to do is go up here to click the minimize window and then click the maximize window and it should snap right out to the desktop size that you have and look at that that's what we have for our remnux install later in the course we're going to talk about the networking required with this but remnux is now ready to go so meet me in the next video and we will keep it rolling we're going to install our primary windows environment which is flare vm so meet me over there all right my friends now we are back at the virtual box manager here and we will remember we paused our flair vm operating system now our primary operating system that we'll be using to do this course hasn't actually been set up yet we do have the windows 10 but we need to install the software that we'll be using for this course so go ahead and click machine and we'll click pause to unpause it and we're back so we'll open up microsoft edge which is everyone's favorite browser to download chrome and go ahead and grab the chrome download and this is a pretty quick setup so just go ahead and click download chrome follow all the prompts we'll get the little chrome installer exe right here and we drop this to the desktop and we'll go ahead and run it and this will set up chrome for us you can click yes for the uac prompt and it will install chrome for us and once chrome is installed we should get a nice chrome browser all right and we got a google chrome browser so we're looking for flare vm this github repository right here now what is flare vm it's awesome is what it is it is a whole operating system install script setup that will install a bunch of reverse engineering and malware analysis tools on a windows operating system it's maintained by fireeye labs advanced reverse engineering team and all we really need to do here is follow the instructions on this install so take a look at the requirements here i think we should be good with this and what we want to do we've actually pretty much sorted out all of the pre-install steps here so we've taken a snapshot of our machine and if anything goes wrong we can always revert back to it now what we want to do is right-click on install.ps1 and copy link address and we're going to open up a powershell prompt and we open this up as administrator so right click and run as administrator and you can click yes and what we want to do is hit enter a couple times until the prompt comes here and set exec policy or execution policy and you can tab autocomplete for that unrestricted and it will say are you sure you want to do this and you can hit a which is yes to all and that should be good now what we want to do is wget oops we wget we can go down here to install.ps1 and copy link address and you're going to wget that right into your operating system and you can do a dash use basic and hit tab autocomplete for use basic parsing and the other argument that we need here is the outfile argument now keep in mind that we're currently in the context of system32 and we don't necessarily want to install it there so we'll do outfile and we'll do c users and whatever your username is so for me that was husky desktop and we can do install.ps1 and that will drop it right to your desktop of your current user and we've got install.ps1 here if we change directories to see users your username for me this is husky desktop and we do a deer command we'll see that my install.ps1 is right here so all we now need to do is dot slash install and we're gonna let this run and this is gonna take a very long time and it says you have less than 40 gigs free disk space left you can go ahead and select yes that's fine password for user husky and you can hit ok to that and this is going to do a full install of the tools in flair vm and it will take a little while so go ahead and let this run and i'll meet you back here when this is complete now after a reset or two it will ask you to put in your auto login password so you can go ahead and put that in mind remember was password for the husky user and it will keep going oh hey remember when i said this would take a while i i was completely serious it takes forever in the time that it's taken and this isn't even done yet i have done my laundry i have paid my credit card bill uh i've done a couple other chores just hang in there if you get any prompts that say do this continue just do whatever it needs uh it does take a while but uh it is worth it i do promise that so i'll see you in a bit all right finally it looks like we've got our flare vm distribution installed if we hit enter here maybe hit enter a couple times here we should be back to our desktop and all we would need to do at this point is restart and we'll put in our password of password and there we go we've got our awesome flair vm background and if you see this background it's likely that our installation has succeeded all right now we are at the single most important part of this whole flair vm installation process if you take one thing away from this video let it be what i'm about to say what we need to do and i think you might know what i'm about to say is go up to machine what we're going to do is pause and we are going to take our snapshot this is the most important snapshot that we're going to make and this is our flare vm bass snapshot and the reason we're doing this is because every time we detonate malware we do not know what has changed on the operating system maybe something was installed into the registry maybe there are now files in a directory that weren't there before maybe nothing happens at all but the idea is that if we don't have a good baseline to revert back to we might never uncover some of the activity of the malware that we're detonating and so whatever happens if we unpause this host and let's say that this readme.text gets deleted and uh i mean if the malware only did that consider ourselves lucky but let's say that happens all we would then need to do is shut this virtual machine down we'll go back to our virtualbox manager and we would go over here to snapshots and we see that we have our base install and we also have our flare vm base if you see this current state changed you know that something has changed between where your vm is currently and where we took the snapshot and what we're gonna do is go back to restore it to the flare vm base and click restore you don't need to create a snapshot of the current machine state if you click restore we're back to our flare vm base and we can start back up and once it restores back to the snapshot state we see that readme.text is still here and effectively our base flare vm install is still good very very important for when we start to play with things like ransomware and things that install persistence so make sure that you do that it's incredibly important to restore to that that good baseline configuration okay but that's it that's our install for flare vm and we're gonna get rolling on setting up the network and then we're gonna start detonating malware it should be a very good time so let's go to the next video and i'll see you right there all right everybody now we are going to set up the network that we'll be using for our virtual machines to be able to analyze malware now we want to do this because we need a safe environment that we can actually detonate or run malware when we drop it in and we don't want to risk our physical operating system that's very dangerous to be detonating malware in an area of a network that can reach your physical operating system so what we want to do is set up a kind of special network we're going to be able to put pmat flare vm and pmat remnucks here are two virtual machines we're gonna put them on a network that is physically separate from our host operating system but logically connected so that both of these can talk to each other but they cannot talk out to our physical operating system so the first thing that we need to do let's go to the tools section on the main gui here and we'll click this button right here and we go to network and in network we have a virtual box host only ethernet adapter right here we're actually going to make our own for this and we're going to specifically make one for a malware analysis network and so what we do is we click create and you may get a uac prompt here asking are you sure you want to do this you can go ahead and click yes to that and so let's go to the adapter tab here on hosts only ethernet adapter number two we will click this dhcp server enable and we notice that we have a 192.16 24 address that's fine but what i like to do as kind of a best practice is to change this ip range so that it's it's noticeably different from something like my home network now my home network is set up with a 192.168. i don't quite remember what the third octet is here but that's not too important the real thing that i want to get across here is to make this into something that is noticeably different from any of the other networks in your area so let's make this into a 10.0.0.1 address right here and so for the ipv4 subnet mask you can leave that as 255.255.2 that makes it a slash 24. and we'll go over once we're done with these settings right here we go to dhcp server and we just have to fill out a couple simple things here first one is going to be setting this to 10.0.0. again we leave the server mask as 255.255.255.0 the lower address bounds we're going to set to 10.0.0.3 and the upper address bound we're going to set to 254. so to recap we have a 10.0.0.1 ipv4 address our subnet mask is a slash 24 our dhcp server is at 10.0.0. and our lower bounds is 10.0.0.3 and our upper bounds is the upper part of the ipv4 range and when that is all done we will click apply and again you may get the uac prompt saying you need to be an administrator to do this just go ahead and click yes now we go to our first vm here and we'll click on that vm and we go up to settings and we scroll down to the network settings right here by default this is set to a nat adapter a network address translation we do not want this this means if you leave this as a nat adapter this means that your flare vm guest operating system can route to your physical operating system by way of its physical ethernet adapter we don't want that definitely don't want that you do not want your detonating malware to be able to route to your physical operating system so what we want to do is select host only adapter and when we click on this we have a couple options here we have the original adapter that we saw and we have number two number two remember was the one that we just set up and we click on that now it's worth pointing out we should check these other three adapters right here and make sure that they are not enabled this one should be enabled but these three should not you don't want some random adapter still live that might be bridged into your network or something crazy like that that's just not good if you're detonating malware we just want complete control over one adapter right here and when we set it to adapter number two we will click ok and we do the exact same thing for remnux we go down here we are in the details section here and we go to settings and we'll go down to network same thing we're natted over here we do not want that we go to host only adapter and it may default to number two here but if it doesn't just drop it down and select number two and check remember we're going methodically we're going slowly here we're doing this correct from the start so we check to make sure that these other adapters are not live and they are not and that looks good and we will click ok now we have both of our virtual machines set up on a host only network and they'll be able to talk to each other but they will not be able to talk out to the greater internet and we will start both of these virtual machines and you can drag that a little bit out of the way and i'll keep both of them here on the screen at the same time as they start up all right when we boot to the main screens here we're going to log into flair with our password of password and remnuck should already be set up right here and what we'll do is we'll check the internet adapter settings so we'll issue an ipa command over here on remnux and we'll go down to the windows machine and we'll type in cmder for commander which is remember our kind of fancier command terminal ipconfig and we inspect our adapter settings and remember we want to be in the 10.0.0.0.24 network and it looks like we are so over here 10.0.0.3 we are good on remnucks and over here 10.0.0.4 we're good on flair vm and the other thing that we want to do is remember we want to make sure that we cannot actually ping outside of this network so let's go ahead and do a ping google.com that should fail good okay but maybe google's dns server is down or something crazy like that let's try pinging 8.8.8.8 that's google's main dns server ping transmit failed excellent that's what we want over here on remnucks we want to do pretty much the same thing ping google.com should fail ping 8.8.8.8 should also fail looks good but can we talk to each other at this point let's try ping 10.0.0. and we are four over here on flare and it's looking good and over here we do a paying 10.0.0.3 and that looks pretty good all right it looks like we have a network that's now set up that two of our virtual machines can talk to each other but they cannot talk to the outside world and we're looking really really good so in the next video we're going to set up a bit of a fake internet situation that's going to allow our malware to be tricked into thinking that it's talking to the internet when really it's not so meet me over there and we'll set that up all right for this next section i thought before we get into setting up our fake internet i thought it would be valuable to go over kind of what this network is going to look like the parts of it and what each part is going to function as and so really what i want to do is break out my new drawing pad for this one so follow me on a journey through the malware analysis network so let's say that this laptop icon right here is our physical host now on our physical host we have a couple of virtual machines and what we've already succeeded in doing is making a network that is going to be shielded from our virtual machines in other words the physical host is acting as kind of the facilitator for everything that's going to be inside of this network but there's no way for the virtual machines inside to actually route out to the physical host so we're basically have a couple of consoles into these virtual machines and they have no network capability back out towards our physical host and that's exactly what we want all right so let's talk about the two virtual machines that we have inside of this network remember this is the 10.0.0.0.24 network and really there are only two hosts in this network we've got over here host number one flare vm and over here host number two we've got rem nux flair vm and remnux flare vm is our first one that we're interested in because it is a windows operating system it is important that when you're studying malware you have a place that you can run the malware otherwise known as detonating it uh that matches the architecture of what it was designed to do so when we detonate malware and i'll draw a little bug here so we've got this guy and he's got some legs and he's got some antenna so that's our bug our malware bug when we detonate this boom it will have its full effect on the operating system because it was designed for the windows operating system now it begs the question why do we have this remnux host which is a linux operating system and the reason for that is because it benefits us greatly to have an operating system that the malware was not designed to detonate within and so what ramnox ends up doing is it ends up being a couple different things one of them is going to be an internet simulator so remnux has this capability where we can set up a little program called inet sim and it's going to respond to any outbound internet requests that the malware is going to make the malware is going to say hey i'm detonating right now i am looking i'm making an http request to some strange website and remnucks with this internet simulator program is going to say oh i gotcha fam go ahead and send me what you got and i will send you back some information so it helps that ramnox is sitting on this network to be able to respond to requests like that there are in fact programs that do this on flair vm but we're going to do them on remnucks so that we have an external location to be able to study malware the other thing that we're going to do in a broader sense is a network analysis platform and so we're going to look at things like wireshark and tcp dump and we're going to take the requests that are coming in from this malware detonation and we're going to study them at the network protocol level and so broadly speaking what we want to do is set up two different locations one that's going to focus on host based indicators and one that's going to help us with network based indicators so let's say the malware detonates boom and it changes some files over here on flair vm and it deletes some files or it adds something or it changes a registry key you're not necessarily going to know about those host-based indicators over here on remnucks but let's say the malware detonates boom and it sends some http requests over the wire we're going to be able to pick those up using our network telemetry meaning wireshark and tcp and the fake internet simulator that we're going to be putting up and that's why it's beneficial to have two virtual machines in this network one to be able to study the host space indicators and one to be able to study the network based indicators all right now enough of me talking let's go ahead and set up the internet simulator and test it so that we know that it works all right and we're back over here on remnux now the program that we want to set up to fake the internet for this malware range is called inet sim i net sim and if you run inet sim it's actually quite easy to start it starts right up and it has a whole bunch of services and these are great but there are well there's really one that we want that's not running right now so we can control c if you hit control c out of that process it should stop and so before we run inet sim again we're going to sudo nano etsy inet sim inetsim.conf file and this is the config file that inetsim uses to run the program and hit enter now if you have not used nano before i will give you some pointers as we go along so that you know how to use the text editor for it but really any text editor that's available on remnux can be used to edit the text of this file so if you find another one on remnucks that you're more comfortable in just go ahead and use that one no big deal anyway we are up the top of the inet sim configuration file and what we want to do is scroll down to this start service section which is right near the top and you'll see that a bunch of the other services are already uncommented meaning they don't have this little hashtag symbol or pound symbol in front of it and we really want our dns server up and running for our malware detonation so what we want to do is remove the comment and you can just hit the delete key to remove the comment to make that a service that will start up so the second thing that we want to do is we want to go find we're going to scroll down to service bind address here and so what we want to do is uncomment service bind address which is set to this 10.10.10.1 delete that and we do 0.0.0.0 and that is a shorthand ip address assignment for all interfaces so this will bind to all interfaces on the host alright next up we want to go find the dns default so we scroll down and we keep scrolling and we keep scrolling and we do find the service dns here right here now our default port is going to be fine as 53 because that's the default for dns but this default ip is what we're interested in so what we want to do is uncomment the dns default ip and if we just leave it to the default it'll be 12700.1 but that's not really going to help us we want this to be the ip address of our rem nux box so what we want to do is set this to the ip remember that the ip in this instance is 10.0.0.3 and we can actually correlate that if we open up another terminal window or we open up a new tab here and we just do a quick ipa we see that our ip address is 10.0.0.3 all right looking good and so if we have done those things we can then hit control o which writes to the file and we leave the file name as default and hit enter and now we can hit control x to save and exit the file now let's start up inetsum again we'll do inet sim and this time we see that our dns 53 tcp udp is actually started along with all of the other services that are running and that's good that's what we want all right now what does inet sim do well to do that we're going to go back to our flair vm box which i've powered down all right so we are back over on flare vm and the reason i wanted to come over here was to show you how inet sim is going to work so we open up google chrome and what we'll do is go to 10.0.0.3 which is the default address of our remnux box and if we go to that address on http we find the default html page for inet sim http server fake mode and look at that it actually serves us out a default page there's not a whole lot here but it does give us a 200 okay and it serves us some html so what if we go to https colon slash and hit enter now it will say not secure because it doesn't have a correct certificate the certificate is invalid but it still serves us out something on the page so if you think maybe a malware sample has detonated and it reaches out for a second stage to some url right this is going to serve it out and respond to that request and say yes i am that address send me your information and so another interesting feature of inet sim is if you go to something like mals.exe and you hit enter it actually downloads something instead of just returning a 404 and so let's take this let's throw it right on our desktop and let's double click what happens inet sim this is the inet sim default gui binary so it actually downloads an executable to our downloads folder now this is useful for something like a piece of malware that operates to download and execute a second stage so let's say that a piece of malware reaches out to some url and it downloads second second stage payload.exe instead of just returning a 404 and saying oh i don't know what that is i net sim actually does respond to it and we'll at least know it won't be the actual payload because it's the same kind of executable every time but it still does download one so let's say this drops into maybe like the temp directory or something like that we could actually go hunt this down and say hey the malware actually got a second stage payload and it actually goes to this directory and we can take that as a fact and record that and there's actually one more thing that we want to do here we'll go down to our start menu and we'll do network connections view network connections and we want to look at our ethernet adapter we can double click on this and go to properties and we'll go down to internet protocol version 4 and we are obtaining our ip address automatically that's okay we can leave that as the default but we want to go down and use the following dns server address and we want to set this to the dns inet sim server that we just created which is the remnux box which is 10.0.0.3 and we'll go ahead and click ok and we'll click ok and we can exit out of this so at this point if i type in any old address so ase ase asd.com it will go to and you know what let's do that again so it shows it from a fresh chrome tab just to to really drive the point home here we open up a fresh chrome tab and we go to asdasdast.com and it serves out the default html page for inet sim the exact same page that we got from punching in the ip address and so what this means is that we now have a functional fake dns server that's going to respond to any dns request that we put in here we can put in free t-shirts dot com and we get inet sim we can put in fancy lad snacks dot info and we get inet sim and the idea is that we're going to be able to get a really good list of every domain name that malware calls out to when we detonate it inside of this network simply because we now have inet sim running at the remnux ip address that's super important and it's a very powerful tool and it will help you out immensely when we start to do the network indicators in this course and now with no further ado we are now at the part of this course where we get to actually detonate malware inside of our flare vm workstation i'm excited for it you should be excited for it let's go to the next video and let's get this party started hey everybody if you're joining me from the last part of this course you should now have the link to the course repository and so that's going to be at github.com husky hacks pmat dash labs so if you go to that you will be brought to the course lab repository github page and after you see this spiffy spiffy logo here you should see a little bit of information about the labs themselves so let's do a quick lab orientation we're gonna talk a little bit about the structure of the labs uh where to go to find different things i do have to point out please click on this end user license agreement and please read this warning carefully uh the long and short of it is that you're about to partake in labs that have live malware in them now the malware that's written for this course by me has been written to emulate real-world malware characteristics while being as safe as possible but this repository does include real life caught in the wild malware and you just need to be very careful when you handle this malware at all times so please do click on this right here please click and read the end user license agreement but also really the warning just kind of summarizes that so please just read that as well now moving on to the structure of the labs the main lab repository folder contains all of the different sections which all map to the different videos in the course and they go in sequential order and so let's actually scroll up we'll go into the labs section here and each of the sections is numbered 0-1 1-1 1-2 generally speaking they're all numbered in sequential order and you will take them in the order that they are shown here and so what you'll do is you'll go into 0-1 during the section that deals with handling and safety and the sample for use in 0-1 is in a zip password-protected folder inside there now in some cases there are two samples maybe more in a single directory so please just make sure that you're using the correct one always refer to each video in the different sections of the course for which sample that you need to work on so for example some of them are used in basic static analysis and used in basic dynamic analysis so just make sure that you're always working on the one that is being referenced in the video now moving on there are the challenge binaries in here as well so the challenge will include the description of the challenge it will include the questions that you need to answer during the challenge and if you get stuck there is an answers directory here which has a readme file in written in markdown that has the answers to these challenge questions here at the bottom so if you get stuck you can go to the answers section but but do try to make it through the challenges without viewing the answers first but if you get stuck go ahead and check out the answers section now back out on the main page here we'll scroll down and in this section we cover the topics of the course so go ahead and read those we have a brief description of the challenges now every sample is zipped and password protected and the password for all of the samples is infected all lowercase right there uh i also have a reporting template so for the report section at the end of the course we'll go ahead and use that so that's in here as well and then please do read this blurb on cosmo to make sure that you understand uh what's going on with the cosmo.jpg uh picture in this repository so you see that i have cosmo.jpg right here and there he is his face is quite big um but yeah go ahead and check that out and just make sure you understand what's going on with that all right and that is the lab repository so again that's at github.com husky hacks slash pmat dash labs and this is going to be every single binary every single sample every single script piece of malware that you need for this course will be in this repository and so to download it all you need to do is go to code and download zip do make sure you're on the main branch here there are two branches but just make sure you're on the main one you'll go to code and download zip and that should download it to your physical host and then you can drag and drop this into your lab environment and then all of the samples will be available in your lab environment for you to use all right and that wraps up the orientation for the lab so meet me in the next video alright so we have downloaded the course repository we have the labs now out on our desktop and we have cosmo.jpg right here very important before we proceed to the next video where we will be detonating our first malware sample we're gonna go up here go to machine and just so that we're all on the same page we're gonna take a snapshot we're going to call this pre destination so once we have our name put in as predetonation we'll hit ok and this will save the machine state before we go about detonating our first piece of malware in this course and the first piece of malware in this course is quite a destructive one go ahead and open up to the lab directory and we'll go down here to bossfight wannacry.exe we open this up when we open up the 7zip directory we use a standard password of infected and we can bring this right out to the desktop in prep for the next video in this course so once again make sure that you have a pre-detonation snapshot to revert back to go ahead and move wannacry.exe to the desktop and again that's found in the labs directory go to the labs directory 4-1 boss fight wannacry.exe and meet me in the next video where we will detonate this piece of malware listen carefully listen closely we are about to detonate malware for the first time now if you're anything like me the first time that you detonate malware even in a test environment your heart might be beating a little bit you might have the jitters but that's okay i'm here to tell you we're gonna get this over with right now and while it never may fully go away this kind of feeling of anxiety when you're about to do this the more that you trust in your own habits and safety when handling malware the easier it's going to become now i have the pmatlabs directory open to the wanacry subdirectory and i have wanacry.7zip right here now what we're gonna do is double click on this and we're going to drag this to our desktop and we have a password to enter the standard password for every single zipped malware sample in this course is infected all lower case i n f e c t e d hit enter immediately you may notice that this malware sample is not in executable file format and we can double check that by going to the properties it is just a file and if we double click on this windows is going to say how do you want me to open this now we can arm this sample by adding a dot exe to the end when you add a dot exe consider this to be a live sample so what we want to do is we want to right click on this and we're going to take a nice big deep breath and we're going to click run as administrator now what i want to point out and what's common among malware samples in general is that at first it may seem like nothing is actually happening there's always going to be more to malware than meets the eye initially and that is part of the reason why we need good snapshots to revert back to because do you know if wannacry just installed itself as a persistent binary do you know if it made a service do you know if it changed a registry key somewhere now we start to see some of the actual symptoms of this infection it looks like they got cosmo and if we try to open cosmo here we're gonna get a we cannot open this because it appears corrupted and we see some other things here wannadecrypter.exe we see the wannacry extension is now on our files and we see this super scary background picture that's been unpacked and it's going to actually change on the background here in a second but the fact remains that at first detonation we may see some symptoms of a malware infection but we don't see everything and even furthermore there might be examples of malware that nothing happens at all to the to the human eye now it looks like this is pretty obviously ransomware right we see the background here and it says oops your files have been decrypted but let's say we double clicked on a piece of malware and nothing happened at all how would we know what was going on and let's say that we ran it again do we know that anything changed from the first time that we ran it so it's very important that we have good snapshots to revert back to and i hope that this illustrates that point we now have a fully encrypted hard drive full of files that are completely useless to us until we fork over some bitcoin to a particular address so this is bad of course and if you see this monday morning when you go into your office you're probably just gonna walk right back out the door right but we are smart analysts and we have the snapshot to revert back to you see that i have my predetonation snapshot here and so what we'll do now that we've seen our little show here is that we will exit out of this vm we're gonna power off the virtual machine and we can actually check this box that says restore current snapshot pre-detonation and when you click this this will get rid of the current state and revert it back to the pre-detonation snapshot and if we start up again we restore the virtual machine state and look at this it's like it never even happened if we get rid of this we can open up cosmo again and there he is and it looks like our machine is completely back to normal and so i want to underscore the importance of this because it's incredibly important for an analyst to be smart and safe when they're handling their malware like this but also it aids in the discovery of the facts related to this malware did it install itself as a persistent binary did it install a service has it changed any registry keys if you run it multiple times do different things happen these are all fantastic questions and we need good snapshots to revert back to if we're going to answer these so i hope that that was an enlightening experience for you we got the first one out of the way together and don't worry i promise you that if you follow the instructions to the t in this course you will not get infected with malware now for now we're going to put wannacry away because we don't know how to handle this piece of malware at this point we don't have a methodology yet to follow to be able to extract facts about this binary so we're going to put it away and we're going to treat it kind of like a boss fight we're going to come back to this at the end of the course and i want you to soak up as much information along the way so that when you see this binary again you can take it down and you can take it down easily so we'll get rid of wannacry for now we're gonna start by learning the methodology of malware analysis which starts with basic static analysis so meet me in the next video and we will get started on the real deep work involved in malware analysis i'm excited to do it you should be excited too so meet me over there hey everybody it's actually husky from the future here you might see a few things on my desktop that are not there or you haven't set them up in the environment at this point don't worry about that what i wanted to do is record a video because something actually just happened to me while i was recording a later video in this course and it actually illustrates a really good point about troubleshooting your own tools so i wanted to just record this to show you what i did in this scenario so basically it goes down like this at a certain point in the analysis sections i went to go use a tool and it was this one right here procmon i double clicked and it said oh we're searching for procbon we don't know where it is oh no it looks like during the installation of flare vm it looks like a few of the tools at least one of the tools did not install properly now what happens when this kind of thing happens do we just give up no absolutely not what we can do is very briefly put our analyst workstation back on the internet and download the required tools so that we can keep rolling on in the course and this is going to apply to the procmon example that i'm about to show but truth be told any time that you run into a tool that didn't install correctly all of the tools in flair vm are open source and available on the internet for free so all you really need to do is google the name of the tool and you'll be able to find it so how do we get our analyst workstation back on the real internet we'll go up to machine and we'll click on settings and we'll go down to our network section and remember that we are on our host only adapter network right here and we're going to switch this back to nat network address translation remember we don't want this when we're actually detonating malware but for the moment just to be able to get back on the internet so that we can get our tools we can go ahead and select the nat network and you might need to just restart here so you'll go ahead and restart all right and we'll log back in with our password and we'll go back to the desktop once it loads up and we should be okay if we go down here we notice the little internet access network icon and so we can test this by going to google.com and there we go we have the actual google.com now one thing to notice is that you might have to go into your network connections here so just go down to the start menu and do network connections you can view network connections and go to the ethernet adapter you can click properties and you can go down to ipv4 and make sure that both of these are going to obtain ip address automatically and very importantly obtain dns server automatically remember that during the setup we actually put in the ip address of our remnux box as the dns server and that allowed us to make use of inet sim but for the real world internet we want to get that dns server automatically so if you click both of those and click ok you should be able to get back to google all right so how do i find this tool so i'm going to start by googling the name procmon and download and as it turns out that procmon is actually a program inside of the sys internal suite which is provided by microsoft now you can download this individually but you can also go download the full sysinternal suite all right now once we've downloaded the sysinternal suite we can just drag that right to the desktop and we can right-click and go to 7-zip and we can extract to sys internal suite slash and that should extract all of the tools in the sysinternal suite out to a folder on the desktop and if we scroll down we see that procmon and procmon64 are right here and we can go ahead and double click on that and run it and so all is right in the world so that's how to kind of cover the installation if any of the installation of the tools goes wrong you can go ahead and put your analyst workstation back on the internet download the required tool and of course what we want to do we want to reverse this as well so go back to settings and we'll go down to network and switch it from nat back to host only adapter on number two remember that was the one that we set up for our analyst network and click ok and the last thing that you may need to do is go into view network connections so type in network connections click on this and we're going to set our dns server again to be our remnux box so remember to use the ip address whatever that is and put that in here so for me that's 10.0.0.3 or 4. i'm not totally sure but i'll check after this video and you can go ahead and click ok on that and then just for good measure we're going to go ahead and give ourselves a reboot and that's how to cover any tools that fail to install during the installation so if that happens at any point in the course just follow that methodology and you should be fine all right and that's just a little bit on the troubleshooting meet me in the next video all right my analysts and training welcome welcome to the dojo i will be your instructor for this portion of the course as well as the rest of the course and today we're going to talk about the most important part of this entire course if you take one thing away from this course at all it doesn't have to be the technical side of this it doesn't have to be how to analyze malware but i want to drive one thing home and that is exactly what you see on the screen right in front of you safety always not safety first safety always what you're about to do is risky by its nature and that's okay because if we adhere to some basic principles we're never going to put our own operating system or our own data and files at risk and so we really want to mitigate a couple of things here so the idea is that we're going to have live malware in an environment a controlled environment that we're going to be able to detonate now the times that you are most vulnerable are going to be when the malware is in transit let's say you find a piece of malware here's our little bug he's got the legs he's got the antenna he's got the other legs now you have an exe that is a piece of malware it is known to cause damage to a system and we want to make sure that we can get this into an environment where it's not going to do any harm before it gets there so the idea is that your executable is going to have a dot exe extension now one principle of safe malware handling is to add an extension to this that will remove the probability that you as the analyst when you're handling this piece of malware are going to accidentally trigger it without you meaning to so let's talk about a scenario so let's say that we have our analyst workstation here and this is totally fine for malware detonation so we can put our bugs and little antenna and legs maybe he's got some eyes we can put our bugs in here and we can blow up our malware and inside of the environment here it's going to be totally safe but remember that this is a virtual machine inside of your host operating system so the risk factor goes up a little bit if you're inside your physical host transferring malware from some outside location into your physical host and then trying to get it inside the analyst virtual machine so we can do a couple things to kind of mitigate some of the risks here so let's say that let's say that our file of interest is a dot e x e right which is the file extension in the windows operating system for executable and that means if you double click this or if you use command.exe to run this the malware is going to run and it's going to do whatever it was designed to do be that good or bad and so one of the ideas is that when you find your malware source let's say you find it on this website that's out here before it even makes it to your host operating system what you're going to try to do is handle this so that the exe extension is defanged or disarmed by adding another extension that does not have executable properties i like to use malz for malwares so i know what i'm working with but this could literally be anything the common malware executable extensions are going to be things like of course.exe uh some of the scripted malware.js we could use something like maybe dll so while you are studying how to handle malware properly you're going to start to realize which ones of these are more dangerous than the others uh some things like txt uh dot md not so dangerous my point is that before the malware makes it into your environment what you want to do is append that file extension with another file extension that's going to defang the malware so that by the time it gets into the host operating system you're not risking inadvertent detonation now let's talk about one other thing that we can do to kind of mitigate the risks of inadvertent malware detonation and that's going to be the way that we handle the malware in a directory structure we're back in the analyst workstation what i want you to do is go to the xero handling and safety section of the pmat labs and what we're going to look for is the subdirectory there called malwarecalc.exe.mals now i want you to pay attention to exactly how this file is named now inside of this directory we have a couple different things here we have this 7zip file which is malware.calc.exe.7zip we have an md5sum.txt we have a password.txt and a sha256sum.txt now i'm naming the malware this it is a standard convention to me there is no real one standard naming convention on what to name malware but whatever makes sense to you you should pick something and stick with it so this could be maybe malware is the classification of malware we don't necessarily know what this is yet although it does say calc.exe so we can make an educated inference but until we know exactly what we're dealing with maybe we just call it malware and then when we get a little bit more information let's say it's a trojan we could call that trojan and then separated with a dot if this is the first time that you are researching this particular specimen it might not have a name yet you might get to name it that's pretty cool uh and then what i like to do is keep the file extension right next to the name and so you know because you know just from name of a malware specimen you don't know if it's a powershell file or an executable or dll what i like to do is make sure that the original file extension is here in the the file name somewhere and then dot 7zip all right so we have our malware specimen inside of this 7-zip file what we can do is bring this out to the desktop and we can open this up and inside we will have our malware specimen itself again notice that there is a naming convention here it's the same naming convention of the zipped up directory and it is just dot mal's to defang the piece of malware so that you cannot inadvertently run this without meaning to now the next very important part here is that if we try to copy this out to the desktop we're going to need to enter a password it is the standard convention in the industry to password protect and encrypt all malware specimens and the idea is that the password is not to keep people out the password is to make sure that the analyst that is about to copy this to their workstation wherever that ends up being knows very well what they're getting themselves into and so the standard password for malware is infected all lowercase i-n-f-e-c-t-e-d and if you hit enter it copies out to the desktop and the final part here is that we want to arm our malware by removing that erroneous extension hitting enter it says if you change the file extension it will become unusable which is ironic because that's the opposite of what we're doing are you sure you want to change it yes and then after we have double checked our system configurations and made sure that we cannot route to our physical host and all of the other safety measures are in place we have handled our malware from source to sync making sure that we don't risk inadvertent infection of our host system and that's when we get to double-click the malware and run and this one spawns calc like it says or does it well for this one yes it does it just spawns calc but you know later in the course maybe there are others that kind of look like they're just spawning calc but they maybe do some other kind of things okay so that was the primer on safe malware handling these procedures are to be practiced at all times during this course so just to recap remember when you source malware make sure that it has a defanged or or d armed extension appended to it make sure to encrypt in a password protected zip directory all specimens and make sure that that specimen is not brought out of the directory until it is in a safe location for detonation and if you follow those instructions you should be safe from inadvertent infection and we're going to move on to the next part of this which is talking about the sourcing of malware and how to find malware from reputable sources so meet me in the next video and we will talk about that hello my analysts if you join me from the last video we talked about safe malware handling and how to delay the risks of inadvertent infection on your host system but that does beg the question where do i find malware in the first place and the answer it may shock you because when i started doing research into this i thought malware was very hard to find and i would have to plumb the depths of the dark web to be able to find samples and i'm here to tell you that's not the case uh it's going to maybe shock you how easy it is to find malware out in the open and more importantly find safe reputable repositories where you can go to collect these samples without risking your host system or your data um what i want to drive home here is that you do not have to go to sketchy websites in the dark web to find these samples uh they're out there at reputable websites how about github github's a pretty reputable website so let me introduce you to the three main repositories and one's really a compilation of other repositories that i like to use when i'm sourcing malware now the first one is the zoo which is curated by yitzif not quite sure if that's how you pronounce that but that's okay this is the zoo a live malware repository uh this is on github so the site itself is reputable and safe to visit uh now this is fill to the brim with live binaries and and source code that you can analyze as well and i do like that a lot because you may start with analyzing just the binaries here and there's plenty to choose from i do believe wannacry is in here somewhere uh but once you get a handle for kind of the the basics of malware analysis maybe you start to get interested in the source code to understand how these things are built and constructed and so the zoo has both of those now you can go out to the main page here and there's actually a section on how to get started installing this but suffice it to say you can effectively just download the zip file right here bring that onto your analyst workstation and you will have more malware to analyze than you know what to do with so that is the zoo the second place that i want to bring up is the vx underground malware source code repository it is once again on github now this one's very interesting because vx underground likes to source malware from various locations i do not recommend going to their main website what i do recommend is going to their github repository and looking through the different samples that they have here now you never quite know what you're going to find here i want to draw your attention to the leaks directory here and if you go you see that there was something uploaded 17 hours ago in the other and look at that that's the babuk ransomware that's been as at the time of recording this video has been a rash of ransomware attacks uh with that ransomware as the uh particular specimen so i don't quite know where vx underground is getting their specimens from and i'm okay with not knowing because they put them on the github repo again you can do download zip and bring that onto your analyst workstation and there are plenty of architectures here to choose from as well lots of this is windows but there are python samples too and mac os all of these are in zip directories again trying to adhere to best practices of malware handling and so the last repository that i want to bring up which is really a compilation of multiple repositories is at zeltzer.com if you don't know who lenny zeltzer is he is a titan of industry he's one of my heroes he does a ton in the space of malware reverse engineering analysis he's been around for a while and he did teach this professionally as well so he he knows what he's doing and he has put together a bunch of resources for malware researchers and analysts and these are not specifically all databases of malware there certainly are many of them but there are other things that we'll actually get into later in this course like any dot run and so there are lots of different things to play around with here but remember the idea is that we don't want to be going to the dark web we don't want to be going to sketchy forums we don't want to be sourcing these uh unethically or from places that you know you risk your your physical operating system to procure these samples they're out here in the open on on the clearweb and they are available for you to download and play around with so for this course however the only required samples are going to be inside of the pmat labs directory here and you see this says pmatlabs main but yours may just say pmat labs every required binary for this course is going to be inside of that directory provided you've downloaded it from the github repository and so that will be all you need for this course specifically but let's say that you get through this course and you're hungry for more and you're saying where can i go to find more of this stuff well i wanted to bring that up just to show you that you don't have to go to these sketchy websites to find this stuff you can go right here in the comfort of your own github repository pull it down and you can reverse engineer and analyze to your heart's content all right and that is the spiel about safe malware sourcing and so let's move it on with our first section of analysis in this course which will be basic static analysis so meet me in that video and we'll get going all right my friends here we go and so we begin the first phase of malware analysis we begin with basic static analysis of our malware samples now if we break down the terminology here basic static is going to mean we have a limited triage approach to the tools and techniques that we're using and static meaning that we are not running the binary so this is going to be a a i want you to think of this as like a first pass without actually executing or detonating the malware and we're going to pick up maybe things that will give us key insights to what the malware could be doing now in this phase it's very early in the analysis and we really will not be able to draw any definitive conclusions without running the binary but i want to liken this to let's say that you have an alien that you're performing an autopsy on and if you just do basic static that's like looking at the alien without actually slicing into it and saying i know exactly what this alien does and how it functions you can't really say that right but basic static would be a little bit like if you looked at the alien's antenna and said all right i wonder what that's for i've noticed that this alien has some antennae on it and maybe that's used to transmit some kind of information and so you can begin to build out these hypotheses about what the malware could be doing nothing definitive but we might be able to find a few key facts here what i want you to do is open up to the pmat labs in the basic static analysis section and we're going to go to the malware.unknown.exe.malsdirectory now when you open this up you will have the 7zip and the password which is of course infected and you also have a readme here now remember that you should normally have the md5sum and the sha256 hash right here but we don't have that the readme says analyst we do not have the file hashes for this sample yet please pull the hashes and submit from the re team all right so so begins our first section here and this is our basic static analysis the first thing that we want to do is pull the file hashes of this sample now we open up and we punch in our standard infected password and we have the malwareunknown.exe.mals sample right here now we don't actually have to arm this sample yet if we're in basic static analysis we don't have to make this executable because we will not be running this binary now the first thing we want to do is collect one of the two file hashes that i like to collect which is the sha-256 sum and so you can type in sha-25 and hit tab autocomplete on flair it should get you to the executable and then following that we will give the name of the sample which is malware.unknown.exe.mouse and we hit enter and we'll take this and we will copy this down into our notes and we can put this into a text file for now but what we will want to do is copy that out to our physical notes that we have out on our host operating system if we have the first file hash we will then pull the md5 sum and same thing malware.unknown.exe.mals and same deal we can take this and we can copy this out excellent so we now have two pieces of information that we can use to fingerprint this sample the sha-256 sum and the md5 sum and this is going to be important for the next section so meet me in the next video where we talk about submitting these to virus databases and seeing if this sample has been seen in the wild before all right picking up from where we left off what i want you to do is on your physical host so outside of the analyst virtual machine back out on your physical host i'd like you to open up a chrome browser or a browser of your choice and what we want to do is go to virustotal.com now virustotal.com is a gigantic repository of lots of different information about malware samples it has file hashes it has files themselves it even has urls and uris and what you can do is submit information to virustotal and ask it hey have you seen this before is this a malware sample that has been seen in the wild somewhere and so what we can do is copy out either one or both of the file signature hashes that we have received and so we go over to the search function right here and we can control v and copy this in and hit enter and so it will search and what is going to happen is it will say no matches found now at the time of recording this these are fresh malware samples that i have written myself and there won't be any virus total hits but as time goes on i would anticipate that this starts to turn up that these are malicious samples and the reason is because as more people submit this file hash or the samples themselves to the file part of virustotal virustotal is going to scan these files and say hey i am identifying certain functions that i think are malicious so what i also want to do is show you maybe what this would look like if it picked up something that was actually malicious so i'm going to use our tried and true wannacry sample here and so what i'm going to do is do the exact same thing md5 sum but instead of the malware unknown sample i'm going to type in wannacry and we'll take this and we will control c copy this out we'll go back over to virustotal and in the search bar we'll search for this one and wouldn't you know it and which is not very surprising 63 out of 68 malware vendors found that this is a malicious file and a lot of them will actually tell you exactly what that is so that's a pretty interesting thing that virustotal knows this file so well that it can pin down exactly what specimen it is but that just goes to the power of these kind of collective databases of malware so that is the second part of our basic static analysis we will submit the file hash to virustotal and see if this sample has been seen in the past all the while we are annotating these pieces of information we're taking the md5 sum and the sha-256 hash and putting that into our notes for a report later down the line and so that's it that's submitting to virustotal and we're going to keep it rolling with the next part of our static analysis all right for our next section of basic static analysis what we are going to talk about are strings now what is a string in the computer science and programming context a string is very very simply an array of characters right so while you and i as humans understand something like a sentence that might say hello world a computer doesn't really get what this is it doesn't have an idea of what a word is it doesn't really have an idea of what a phrase is but it does know each of these individual characters and so strings are very useful to humans but not so useful to computers but humans need strings in programs to do lots of different things if you think about maybe a programmer is trying to get a program to talk to https colon slash google dot com that is a string a computer is not really going to know what that is but it will treat it as an array of individual characters so it will say this is the zeroth part of this array this is the first this is the second the third the fourth the fifth would be the space right here six seven eight nine ten and then there's actually one final part right here which is a null byte which means that it is ending the string and saying this is the end of the string don't go any further than this and so that would be the 11th element of the array so that's a little bit of background about what a string is to a computer but what does it mean to a malware analyst well like i just said if the malware author wants to program the malware to reach out to https colon slash slash and then this could be any malicious domain dot com slash and this could be evil dot e x e the malware author needs to code this into the program at some point so that the computer can assemble this array of characters into a string and make some kind of web request to it and this comes in the form of a string that is embedded right into the exe i want you to think of an exe as kind of like this box right and so when the box is assembled or compiled there are lots of different bytes that are inside of this box and one of those bytes might be http colon slash domain dot com and so if you can reach inside of this binary and take a look at the strings inside it might inform what the binary is doing but you can't really draw any absolute conclusions out of this the best that you can get really out of looking at the strings is a brief glimpse into what might be used as a sentence or a phrase or a word or maybe a url inside of the binary now let's take a look at how we can extract these strings out of the binary now as i previously mentioned when the binary is assembled these strings are kind of just sitting inside of the binary and can be read by looking at the bytes of the binary and we don't have to run the binary to do this and so we can extract the strings out during the static analysis phase there is a program called strings that will do that it'll look at the binary and pull out all of the strings the arrays of characters and present them to us but there's actually another program that i like to use a little bit more and it's called floss so thanks strings floss it's like a better version of strings which is made by the fireeye team that is going to do just that it will pull the strings out of the binary but it will also try to decode and de-obfuscate any strings that it finds uh with a little bit of programmatic magic on the back end and then present us the strings at the bottom of the output of this program so that we can more easily get an idea of what the strings are inside of this malware and what we might be dealing with so again we will do our malware.unknown.exe.mals and we'll use the program floss and hit enter and so depending on the size of the binary this may take a little while or it may be pretty much instant and so this binary happens to be pretty small so what you see here is floss takes a look at the bytes inside of the binary and it pulls out any array of characters that are greater than length four now it will treat that as a string and say hey i found an array of characters that is larger than 4 bytes and here it is and it's terminated with a null byte that might not be great always now we can see some of these strings are completely useless uh this doesn't mean anything right this is just a random array of bytes inside of the binary that may be serving some kind of programmatic function but it doesn't really tell us a lot about the words or the phrases or the urls that are used inside so the idea is that not all of these are going to be useful but every now and then you're going to come across one that's incredibly telling as you can see here i didn't really do a lot of modification when i was writing this malware so you can actually see the exact path of the malware in my repository from the original compilation my pmat maldev repo right here is where i was writing all of this malware now you may get very lucky and see something like that but you can just kind of keep scrolling and after you get through some of these other less useful strings you start to see some other things in here and this is actually kind of it ties into another part of the static analysis phase that i'm going to cover later but you start to see these things like internet open url w internet open url wininet.dll to a trained malware analyst some of these are jumping out immediately url downloads to file w now to someone who's not really familiar with what this could be what could these things be well maybe they are the names of functions or maybe they're the names of uh things that the binary is doing and as we keep scrolling we see a few more of these and then eventually we get to the very bottom of floss where floss is going to pull out the static unicode strings and these sometimes are some of the most telling of all of the things that that floss will pull out and so we see things like cmd.exe and then cmd looks like it's running some kind of command here and we see things like http colon slash ssl and then maybe like a a domain name here help desk bros.local favicon.ico we see something in the users public documents directory right here now what we should be careful here is that these may be thrown into the binary intentionally to trick us or they could be actual pieces of the binaries functionality we don't know at this point but certainly all of this right here is very interesting and so what we want to do is take note of this and maybe like think of it like putting a pin in this right here so we're going to take like a little a little pin and we're gonna put it right in that cmd.exe and say i don't know what the string is doing but now that i know that it's in there i'm gonna take a look at the things that are using this string and maybe some of the stuff that happens around it and so we see some very interesting information here but again at this stage in the analysis there's just not enough to go on we really need to start to go deeper to figure out what these strings are doing and why they're in here but in any case extracting the strings out of a binary can be a very informative first step at identifying where to go next so it's very important to do so that is string extraction and we're going to be moving on to our next section of the static analysis so meet me in that video all right analysts we have looked at the strings that are setting inside of the binary we have used a tool called floss in order to extract them and in order to look at the structure of the binary and maybe find some more information about when it was compiled and what kinds of functions it might be using we're going to go to this flare directory right here which is a shortcut to the programs directory and we're going to scroll all the way down so go all the way from the top and find this utilities subdirectory right here we open up the utility subdirectory and we're going to scroll a little bit of the way down and we find these pe programs right here we want to open up pe view so double click and open up pe view and when this opens up it will ask you what do you want to load into it and it will try to find an executable as a default now we don't have our malware sample in executable format so we can go to all files and what we want to do is find our malware.unknown.exe.mouse double click that and load it in now what i want to point out is that this right here in the center is is kind of a very interesting way to think about what a pe looks like now you think like with a powershell script or maybe a text file you kind of know what it looks like when you open it up right you see some characters and maybe some sentences and maybe some some if it's powershell maybe you see some functions in there but can you honestly say what does a portable executable look like like really when you think about it what does it really look like well when you open it up in something like pe view you get an idea of what these things are actually made of and what it comes down to is that a portable executable is really nothing more than a gigantic array of bytes and you see these bytes are represented here in hexadecimal format and you'll see the raw data are the hexadecimal bytes in the center you see the p file column right here represents the offset of these bytes so where in relation to the beginning of the program did these bytes exist and all the way over here on the right side you'll see the value column it's a character representation of what these bytes look like sometimes they are actual characters and sometimes they're not able to be represented and that's when you see these dots right here but truth be told all of these bytes have some kind of purpose inside of the binary now every portable executable follows the same exact format it starts with this byte right here which tells the file system and the operating system what kind of file it is this mz right here is a signature giveaway that this is an a a windows portable executable and this is actually someone's initials i actually learned that recently and so following this magic byte right here that tells us that this is an executable a little ways down from this we can actually pick out a sentence right here this program cannot be run in dos mode this is the dos header of the portable executable now i'm not going to go through the whole anatomy of a pe that's kind of outside of the scope of this course but what i want to get across is that all of these programs follow a very very particular format and so something like pe view was constructed to tear apart this format and look at all of the different sections and we can extract a lot of insight as to what this executable might be doing from looking at these sections now one of the first things that i like to look at is to go right down here to the image file header which is under the image nt headers section and so one set of bytes inside of the portable executable will have the time date stamp the time date stamp is a time of compilation for this particular executable now the time date stamp may in fact be a reliable point of information but it might not there are some circumstances in which this time date stamp is going to be the same no matter when this executable was actually compiled now for this one i did happen to compile this today you see the calendar down here is 9 4 20 21 and you can see up here that this was compiled on 9 4 20 21 so the date time stamp of this executable is accurate but let's say what if this said 1992 some date in 1992 that's pretty old right it's not necessary that that particular executable was compiled back then but that might be an indicator of some other kind of information the borland delphi compiler so malware written in delphi if it was compiled with the borland delphi compiler it will always have a timestamp of 1992 a date in 1992 and so this can be a reliable piece of information but you you really need to look at it carefully and critically to determine if that was actually when it was compiled so let's move on from the date timestamp down to the image section header of the dot text section so the dot text section is one of the about five locations in the binary that has information that can be read into the binary at runtime so one thing that i like to look at here are the virtual size and the size of the raw data you can compare these values these are going to be written in hexadecimal and so what you can do is break out your trusty programming calculator and you want to take a look at the virtual size and the size of the raw data for both of these fields now if we select the hex section of our programming calculator and we type in the size of the raw data 1600 in decimal that means that that is about 5 632 bytes now we take that number and we compare it to the virtual size here one five a one so let's go ahead and go back to our programming calculator and one five a one and it looks like that is five thousand five hundred and thirty seven now if these two values are similar we can ascertain that the size of the raw data of the binary is roughly the same as the virtual size you can think of the virtual size like the amount of data on disk when the binary is run now let's say that this was much much higher than the size of the raw data so the actual raw bytes inside of the binary are actually much much lower than what it is when it's run and what we could maybe surmise from that is that there is more to this binary than is initially available to us and we can maybe think that that's what's known as a packed binary so i do like to look at these take a note of these and make sure that these values are relatively close if they're not we may be dealing with a packed binary and a little bit later in the course i'm going to show you exactly what that looks like now i want to look at one final piece in pe view and if we go to the section of the r data and look at the import address table this might be one of the most important parts that we can see inside of pe view now to really understand why the import address table or iat is so important we need to look at something called the win 32 or really now just the windows api now to explain the windows api i think i'm going to break this into its own video because it's a very interesting topic but it can be a lot at first glance so i want to make sure that we break it down so meet me in the next video we'll briefly cover what the windows api is and then we'll go back to why the import address table is so important for this phase of malware analysis so meet me in the next video all right now we're back and we're talking about the windows api now api stands for application programming interface now i want you to think of the windows api like this way back in the day when the very very smart people who designed the windows operating system were working on it they said hey we work on the operating system all the way down here which is a very low kind of code to be working on now down at the heart of the operating system you're really dealing with things like zeros ones and instructions like jump and xor and lots of very very low things like that right now as the operating system developed certain features of the operating system were developed as well and so the programmers decided hey instead of requiring people to be working all the way down here at the very very gritty low operating system level why don't we expose these functions of the operating system so that anybody who wants to design a program and write a program in something like c or c plus plus can make use of these functions instead of tapping into the the very very low code of the operating system and so what you can think of these functions is easier to work with versions of these very very low level programs that are running inside the operating system so the windows api can do things like hey if you want to download from url you can use this api and in your c or c plus program instead of writing a whole bunch of low-level code you can just say download from url and then you would define that in your program and so as part of the windows operating system we now have this application programming interface called download url and so if we want to use that in our program we need to supply it a few things we need to say which url to go to and which file to download and where do we want our out file and what will that file be called and so microsoft put together documentation that says hey if you want to use this program inside of your own program you just need to supply a very specific defined pattern of information and thus the windows api was born now programmers all over the world can make use of all of these functions all they have to do is import them from the operating system now is the windows api bad no no it is not many different programmers from from many different walks of life are able to use the windows api for all kinds of programs but that means that malware authors can use it too now if we look at the import address table we start to get a feel for what kind of api calls this portable executable is making and so right off the bat to the untrained eye none of this might look really that interesting but there are a few things that jump out to me so when you see something like shell execute w if you don't know what that is maybe all you need to do is open up the documentation for it so we go right over here to old googles and we're going to say the windows api shall execute now microsoft has documentation for each of these functions so shell execute a performs an operation on a specified file so this is an example of one of the api calls that a program can make you can tap right into the operating system and call this and it has like a built-in function to allow you to do some kind of thing so that is definitely something of interest again we don't have enough to say that this is definitively evil at this point but it is a very big indicator and if we keep looking we're going to see other things that might be indicators as well how about this one url downloads a file that was kind of the example that i was giving when i was explaining the windows 32 api well here is the actual api call again if you don't know what this is go over to the googles and we're gonna do url download to file downloads bits from the internet and saves them to a file now that can be pretty telling but a lot of different programs might use that kind of api call uh maybe spotify uses that to download playlists uh maybe your bank application uses that to sync your information to your accounts but if we already know and anticipate that this file has malicious functions this is a pretty big indicator that this malware might be trying to download some kind of second stage executable so again you can look at the different parameters here of how this function is invoked or called and all it really requires is a url to actually download from the file name and it will write that file to the file system somewhere so this is the import address table this can be very telling about what a piece of malware is doing at any given point but we don't know if these programs are even invoked yet because we have not run the binary and that wraps up looking at pe view to identify a few of the characteristics of the import address table the compile time and some of the different section headers and so we are going to move on with our static analysis hello my friends so we're back it is about a month a little over a month since pmat released and one of the most common pieces of student feedback was that hey during the import address table and windows api analysis sections you've underscored the importance of analyzing apis to identify malicious use but i'm confused at which ones i should be scrutinizing because there are so many and i'm not sure which ones can be used maliciously so i think this is one of the cases where when you ask the universe for something it sometimes provides it because a few weeks after the course dropped a researcher by the name of mrdocs on twitter which you can go find their their twitter right there they released this which is mal api dot io this is a phenomenal resource and it just fits the needs so well of what that piece of feedback was looking for now you won't be able to get to this in the lab of course you're going to need an internet connection for this so on your physical host you can go to mal api dot io and so what i liken this to is if you took something like gtfo bins and something like the miter attack framework and kind of put them together this is a little bit like that it's specifically for the purpose of cataloging windows apis that can be used maliciously and identifying samples of malware that those apis are used maliciously in and so it's just amazing because mr doc's put together this this set of columns that are going to identify each of the apis by usage by ttp uh injection evasion spying internet usage anti-debugging and so what you can do is you can go and click on each of these apis as you see fit so let's uh go ahead and find one of the most uh you know infamous api usages which is create remote thread so when you click on a particular api usage you'll get the name of course you'll get a description uh you'll find the library that the api is loaded in from so this one happens to be from kernel 32 and so associated attacks is again a little bit like the miter attack framework where we are classifying in an abstracted way how these apis are used maliciously and then of course you're going to get the documentation so the actual msdn so you can go ahead and open that up as well and you can go see the exact parameters that are passed in to this api now what's interesting is that in some of these api entries you will get a malware sample of a piece of malware that actually uses this api now in this case this one is linking to the vx underground github page and you can see that the cbot.7zip sample right here is going to use this create remote thread so if you want an example of a piece of malware that's using the api in some of the api entries you'll be able to find that there so the other cool part of this is that mr docs has made this kind of like a community contribution effort so that you can actually go and contribute to this let's say during your research you identify a particular malware sample that's using an api in a malicious way you go to malapi.io you take a look around you say hey it doesn't look like that api is cataloged here well you can go right up here to contribute and you can fill out the contribution guide and mr docs will add this to the api catalog so fantastic stuff there the last interesting feature that i want to point out here is that we have again similar to something like the miter attack framework matrices we have the mapping mode here let's say that you're performing research on a particular specimen and given that specimen you've identified a few api usages let's say the malware starts by enumerating all the processes and calls that api to do so then it creates a process in a suspended state with a create process a api call and then it creates a remote thread and injects right into it and then let's say the malware invokes the sleep api to put itself in a sleep state and then it will open a request to a url and it will download a file and write it to disk and so you can select each of these apis to highlight them on the table and then what you can do is hit export table and this will export a png of this table that you can then take a screenshot of and include in your report as a mapped out set of the apis that the malware is using so very good for report writing so that is malapi.io uh go ahead and send mr doc some love please follow them they're putting out fantastic research and check out mao api.io and that's it for this video thank you and let's move on to the next section to pack or not to pack that is the question at least if you're a malware author that is the question now when we talk about packed malware what are we really talking about here basically packing you can think of as kind of like a compression or encryption mechanism to make a piece of malware look different than its original source so you can think of this it's a lot like if you put a bunch of files into a zip file for example you'll throw it into a directory and a computer program will look at the directory and say okay for all of the strings of characters that look like this i'll just crunch them down and replace them with something like this and that's basically how compression works and that's also kind of how packing malware works it's basically just a compression of an already existing piece of malware so as always let's draw it out let's say we have mouse.exe and this is a very well-known piece of malware and it's been going around for a while now well let's say that our malicious author takes a packing program and in this case we're going to use a packing program called u p x which is a very popular packing program and upx is going to take this piece of malware mals.exe and it's going to blow it up like this and it's going to say all right this is all of the data that's actually inside the malware all right awesome what upx is going to do is put a little program in here called a packer stub and sometimes this is called a compression stub or a coater stub and what it's going to do is say all right the compression stub is going to take all of the code that's located below this point in the program and it's going to crunch it down and so when this program is compressed like this the resulting program looks a lot smaller than this right it's really now got three sections it's got the original portable executable header like this and it's got the compression stub and then it's got a tiny tiny little piece of code right here and so at runtime this stub will take a look at all the code inside of this part of the program and say all right time to go to work it's going to take all of the code that's inside of that section and then expand it to be the original size and it's going to do that at run time now why might somebody want to do something like this well if you think about antivirus let's say antivirus is on the lookout for things like this this original piece of malware that we have over here if antivirus knows the signatures of this original piece of malware it's going to know exactly what it looks like but it might not know when antivirus you know shines its big spotlight right here on this tiny little piece of malware that's got the stub in it it might say oh you know what that doesn't look like any signature that i know of i think it's totally fine and after antivirus takes a look at it when the program then inflates and becomes the full-sized malware program mouse.exe the antivirus is not going to know how to handle it so that is effectively what compression and packing malware looks like and you can really think of it like it's just a way to make an existing piece of malware look different on disk to antivirus and other kind of security products now to illustrate this point i have made two exact identical pieces of malware inside of the basic static analysis directory go to the malware packedandnotpact.exe directory and open this up it's got our usual password md5 and sha256 and go ahead and open up the subdirectory in here and you can copy both of these out to the desktop again we have our standard password of infected all right now we have malware packed and malware not packed right here and we're going to go back to our program pe view so remember go to the flare directory on the desktop and go to utilities and we're going to scroll down and open up pe view and again it will ask us for a program let's go to all files and let's start with the not packed malware now this should look pretty familiar because we just did this for another piece of malware and we've got the full program here and actually this time it's pretty big by the looks of it and we can see that we can read a bunch of these strings we can see we might not exactly know what they're doing but they are human readable at this point use http keepalive feature print version number and exit stuff like that so all of these uh strings in here are readable by us and we can see that the the layout the portable executable structure of this binary looks pretty much the same as the one that we saw when we did the analysis the first time so we have our section headers which has all of the strings that are located for the binary in the text section we have the resource section which has other strings that may be in the binary we've got the data and the uh our data and we've also got the import address table here and as you can see even though this is a pretty simple binary the import address table is full of all of these api calls that this binary might be using and where they are imported from so we see that kernel32.dll is imported to make use of all of these api calls and now we're not so much worried about what's going on in here remember this is just a very brief example but remember that this is an unpacked piece of malware it's very easy to decipher what's going on because the import address table is full of lots of different things and if we look back at the malware itself there are human readable strings in here that can maybe tell us what's going on so let's close out of that and let's open pe view again and this time we're going to look at the packed sample so we're going to select instead of the notpac.exe we're going to select packed and we might not see much yet but right off the bat there are a couple differences here and we see some things like section upx right here and so upx is the name of the packer program that was used to pack this particular piece of malware and so we see that all over the place really it says upx0 upx one two of the sections are named after that now something very interesting here is that we still have an import address table but look how small it is now remember i told you that packed and not packed are identical copies one is using a packer program so when we look at the import address table and it ends up being this tiny tiny little thing even the simplest of windows executable programs would have more imported api calls than what we see right here but we see a couple that are very very telling get proc address and load library a are two api calls that are used to identify other imports at runtime so instead of something like the unpacked version which has all of the imports listed out in the iat this packed program has to actually go find them from the other dlls that it loads in so it doesn't know where those api calls are directly but the existence of get proc address and load library a say to me hey i don't have these address imports in my table right now i've got to go find them and so what's happening here is that when the packed piece of malware decompresses or inflates back to its original size get proc address and load library a are invoked to be able to find those other api calls and that's why they're not listed in here let's say this program reaches out to the internet and downloads a file remember there was the download file from url api well that may very well be a function of this malware but we won't know that just by looking at the iat because it's packed and get proc address and load library a need to be invoked at runtime to be able to find that that api to use now one final thing that i like to look at with packed malware is something i actually pointed out in the first section when we looked at the iat of the first piece of malware and what ends up happening is that the size of the raw data and the virtual size now have a significant difference if you crunch the numbers on what c00 is in hex it's a certain amount of bytes it's not very high but it is you know a non-zero number but look at the size of the raw data the size of the raw data is actually completely zero and so if the virtual size is non-zero and the size of the raw data is zero we know that we're dealing with a packed piece of malware because the size of the raw data is not represented in a numeric form but the virtual size is and that is because the raw data doesn't exist yet it needs to be initialized after the binary inflates from its packed state so that is the wrap up on packed and not packed malware it can be very interesting to look at the differences here but know that a piece of packed malware is really not going to tell you much about it until it actually runs and so that segs into our next section where we need to start thinking about basic dynamic analysis in which we actually run the binaries to be able to know what they do and just for the curious if we arm these binaries by removing the dot mal's extension and setting them back to exe and we run both of them well looks like they're just calc.exe again all right my analysts now for this next one we're going to go back to our original malware sample that we were working with so malware.unknown.exe.mouse now what i'm about to show you is a tool that might be one of my favorites to use during the initial basic static analysis phase now as it usually goes in cyber security when people started developing out their methodologies for doing static analysis of malware people started iterating on these tools and making better versions of the same tools so if you think that in the static analysis phase we've looked at the strings inside the binary we looked at the iat we looked at some of the the headers inside of the binary and we looked at some of the bytes inside that had key pieces of information now we used a couple different tools to do that but eventually people thought why don't we just make a tool that does a lot of those different things and so there are a few of those but one of my favorite is pe studio so go ahead and go to the flare directory on the desktop and we're going to scroll down to the utilities section again and yet again we will scroll down until we find the slew of pe tools and we're going to open up this one right here pe studio now when pe studio opens up you can either drag and drop a file into the the window to analyze it or you can go to open file here and we'll go to the desktop and we'll select malware.unknown.exe.mals now pe studio does a bunch of things automatically and why it's one of my favorite tools is because it makes the early stages of static analysis very very simple and straightforward so let's look at some of the information on the screen right now right off the bat we already have three of our file hashes that we can work with we've got the md5 we've got the sha-256 which are the two that we've been using in this course and we even have the sha-1 right here now if you are on a system that is connected to the internet which again i don't recommend but if you are you can actually click on these file hashes and if you see the link right there it'll send it to virustotal to check that file hash for you so that actually takes care of the second step now alternatively if you're on a lab system that does not have an internet connection the way that we've set our lab box up to you can of course copy out this file hash by copying the values and go to virustotal and submit them it also has both the hexadecimal representation and the text representation of the first bytes of the file now this can tell us if it's a portable executable by this first magic byte right here we see the mz so we know that this is a windows portable executable it's got the total size and bytes and it even has the architecture and we're working in a 32-bit architecture with this portable executable now there are so many other sections here that we can go into to take a look at other kinds of things pe studio has kind of an additional layer of analysis that it likes to put on top of all of the other kind of basic information about a portable executable and so one of those layers of information is the indicators pe studio has as part of the program a bunch of information about certain strings or patterns that it sees in a portable executable and if those tend to be malicious or not and you see that we have the indicators here we go by level from most severe to least severe and it picks up a couple of things right off the bat the file imports symbols the file references a url pattern and here we see that we have that url that we saw earlier in the strings as i mentioned earlier in the course there are certain libraries that are not necessarily evil right out the gate but they do imply that there may be some kind of malicious intention behind them now once we get an idea of some of these indicators we can go into the different sections and take a look at the the specifics of this binary and we can look at things like the libraries now these are all of the dlls that the portable executable loads in to be able to execute its program and some of these are pretty benign kernel 32 you're going to see a lot all over the place shell 32 you're going to see all over the place but we do have this column here that i will refer to as the block list not necessarily the name of the column itself but that's what i will be referring to it in this course and you might be able to see that some of the dlls that are imported are likely to be used in malicious software like url mon and wininet and let's say you don't know what these libraries are or maybe what they do well we also have a description field over here and so url mon and wininet are noted as potentially malicious because url mon is the embedded library for ole 32 extensions for windows ole is object linking and embedding which allows different microsoft office components to talk to each other and is constantly used for malicious software purposes and when inet.dll is the internet extensions for windows dll and that's not of course by itself malicious but is commonly abused by threat actors and cyber criminals to download things from the internet uh open up sockets that kind of thing and then the last thing that we want to look at is the strings of the binary and of course we've already covered the strings but there is again an additional layer of analysis that's happening with pe studio in which we can sort by the string value we can look at the size of the strings and sometimes the bigger strings are the ones we want to be paying attention to but of course we also have the hint column here which is also very interesting so the hint column is very interesting because pe studio will take its best guess at what it thinks the string is doing and we can see that it identifies some of these ping and open strings as utility and that's pretty spot on right uh it also identifies mozilla 5.0 as a user agent spot on so pe studio is pretty good at picking this stuff out and if we rank by the bad list here we can take a look at some of the strings that pe studio is saying these are likely to be abused and it looks like they've got a couple ones that are interesting here of course url download to file an internet open url two common apis that are used for malicious purposes and pe studio has flagged those as bad strings and so all of this is to say that when you sit down to start to do your static analysis of a binary pe studio can be a very very powerful application to help you speed things along so that wraps up our basic static analysis section we're going to move into the basic dynamic analysis which means that we're actually going to start running the binaries inside of our lab and recording what we see and i think that we're now pretty well set up to take these little pieces of information from the static analysis section and apply them in the basic dynamic analysis section to find out more about these binaries and what they're doing so meet me in the next video now before we go any further let's make sure that we review our notes so if you have not been taking notes up to this point i strongly recommend that you start if you have been taking notes let's compare notes to see what we have so far and really when you think about it coming out of the basic static analysis portion we're not going to have a ton to go off of but there are a few things of interest so just to briefly cover some of the things that i saw in the basic static analysis portion we of course got the file hash we have the sha256 and the md5 some hash which are right here we also submitted this to virustotal but there were no results at the time of submission this may be different by the time that you're taking the course but for right now there are no results for these two file hashes now some of the more interesting pieces of information that we found we have the strings and the floss output from this binary and right off the bat we have some inferences and maybe some hypotheses of what could be happening with this binary we don't have anything definitive of course but we do want to make sure that we're being very scientific and recording some of the things that we extract out of the binary and right off the bat the strings that we have coming out of the binary may be very telling about what's going to happen in the next phase and we don't want to we don't want to say anything definitively yet but we will be taking these strings into the next phase of analysis and verifying to see if any of them hold any weight and of course when we reviewed the iat and looked at it in pe view we saw that there were a few import address table calls to some api functions of note we found shell exec internet open url a and download from url now each of these could indicate malicious functionality inside of the binary again it is too early to tell but we'll keep that in mind for when we move into the basic dynamic analysis portion and i'd just like to remind you note keeping in this is so so important so make sure that you're keeping good notes the whole time so we're going to move into the next phase of analysis and we're going to expand on that as well hello my analysts all right if you're joining me from the previous video we have just wrapped up our basic static analysis of the first sample in this course now let's go back to the metaphor remember that we are scientists and we have an alien in the lab on the operating table and during basic static analysis we have effectively stood over the alien with a clipboard and a pencil and we've pointed at a few different parts of the alien like its antenna or its eyes or its limbs and we've said i wonder what this does i'm taking note of something on the outside here and i have a hypothesis of what it might be doing and that is basic static analysis it's a very good starting point pulling the strings looking at the iat these are all good starting points but nothing nothing is going to tell us more about what this binary or this sample in general may be doing than actually running it and to find out more we need to now move into dynamic analysis this may also be known as heuristic or behavioral analysis you may hear people say one of these terms heuristic analysis behavioral analysis dynamic analysis they are all effectively the same thing now we are starting at the basic level of dynamic analysis and according to our methodology that means that we are taking a triage approach with a limited set of tools and a limited amount of time to look at what this malware might be doing and the key fundamental difference is that we will be running the piece of malware in the lab at this point now when it comes to dynamic analysis there are two categories of information that i like to think about dynamic analysis is going to tell us a lot about the host indicators and the network indicators now you can think of the hosts and the network indicators as two sides of the same coin when something happens on the binary on the host maybe it deletes a file delete file or maybe it installs itself as persistence installs persistence these are host based indicators because they happen to the host that the malware is detonating on now on the other side on the network indicator side let's say the binary calls out to a domain maybe it downloads a file these would be network indicators because we have some kind of network indicator to hone in on to identify what the binary is doing now there are some indicators that kind of tread the line between these two areas so if you think about something like a dns request well dns is definitely out on the network side but there's also a certain component of windows logs that can pick up when a process makes a dns request so sometimes a dns request might be a host-based indicator if it's being pulled from a host log or it could be a network indicator if it's being pulled from network logs or identifiable on the network wire now it doesn't really matter which indicator you try to look for first there's really no rhyme or reason to it as long as you're covering both of these indicators thoroughly and making sure that when you detonate the malware you can get an idea of the things that happen on the operating system i.e host and the things that happen on the wire ie network and if you can get a good idea of both of those you have really really good information to go into the later phases of analysis so without any further ado let's get going all right my analysts we are ready to get into our basic dynamic analysis portion of this course so before we do that a couple of things to think about first thing to think about is that we have a certain amount of notes now and we should let this inform how we perform our basic dynamic analysis in other words from the strings that we've pulled out we already have a bead on a couple of potential indicators host and network indicators so we'll be on the lookout for things like this and i'll show you exactly how to apply that and what to look for here in a moment but the other thing that we have to worry about is making sure that our tools are up and ready to go as far as the detonation of this malware is concerned so i want to start by doing something here if we don't have all of our tools up and running let's say we arm this piece of malware and we say all right it's time to see what this does and we double click and we get a command prompt window briefly and then the malware disappears and so what just happened well we're not totally sure right because we didn't have all of our tools up and running and ready to go now one thing that this malware does is that it reaches out to a domain and tries to see if it's online and in a sandbox without an internet connection there's not going to be any domain for the malware to contact and the second part of the logic of this malware says hey if you don't find a domain there go ahead and exit out of the program and delete yourself from disk and so that can be very detrimental to our analysis because what if that was the only copy of that sample that we had on hand now we've got to go track down the sample again so it's important to make sure that all of our tools are up and running and ready to go so remember that we have our remnux box over here that's serving as our internet simulation or inet sim capability and remember that we have it set to be our networks dns server as well so go ahead and on remnucks make sure that you're running inet sim and the other thing that i like to have during the basic dynamic analysis portion is a listening instance of wireshark so go ahead and type in sudo wireshark and when the wireshark gui comes up you can go ahead and click on the main adapter here and click this blue shark fin icon and you can start capturing packets there's not going to be a whole lot going on remember that this is a completely isolated network but we can check this now by opening up a web browser and we can go to google.com and remember inet sim will serve us the default internet simulation page and if we search for something like tcp port equals 80 and click go we can see that there is now traffic being generated here so if we go to something like h http colon slash free t-shirts dot info we'll be able to see that request to free t-shirts dot info and we can look into some of the different headers in wireshark to go find that so in any case all we're really doing here is making sure that our internet simulation capability is up and running and that we have our tools ready to go so we can exit out of that and let's open up the labs again we'll go back into the basic static portion remember that we're using the same sample here and we'll bring this over to the desktop infected is the password again all right and we're moving out of basic static into basic dynamics so what we'll do is remove the dot malz extension and change this to our executable format now if we examine some of our notes from the basic static analysis we already have a couple of things that we can drill down on to see if we can find more indicators when we run the malware itself so there are lots of things here and we can kind of break these up into the host based indicators and the network based indicators now something like a url right here so we see this ssl-6582 data manager dot help desk bros.local favicon.ico that would very much be a network indicator or at least a potential network indicator so why don't we take a piece of this and we're going to copy this favicon.ico right here and we're going to use the tools available to us to identify more information about the network interactions that will be taking place so let's go over to remnux where we have our instance of wireshark running and we're listening on our main interface and what we want to do is take a piece of that information and see if we can search within wireshark and filter the packets that are going to be coming into the server to identify more information about these web requests so we're going to do something like http dot request and you can kind of see it right there in the in the autofill dot full underscore uri and then wireshark's display filters can do things like contains or does not contain or it can search for a string so we can say something like contains and we can put in the individual piece of information that we're looking for which in this case is favicon.ico nothing's going to be shown yet because we haven't detonated the malware so let's keep this to the side right here and we can go ahead and double click on this and watch wireshark for a network indicator and wouldn't you know it we do have one in fact so let's take a look at what just happened when we detonated the malware we did get a request to a web uri that contains favicon.ico so let's look at the different sections in wireshark to see what what actually just happened under the hypertext transfer protocol header it looks like there was a get request for favicon.ico using mozilla 4 as a user agent and the full uri actually matches the one that we saw in our strings output so we've got a pretty good correlation of indicators here we pull the string out of the binary and we searched for part of that string in wireshark having set up this remnux box to catch the internet traffic that's outbound from our analyst workstation and now we actually have a packet that's headed out to this particular uri trying to get favicon.ico i'd say that's a very good set of indicators so why don't we do this we will bring this to the side and i'm going to use green shot to actually screenshot this and we'll copy this down and we'll bring this back over and we'll say something like network signatures and we'll copy in that screenshot so remember that we're after as many pieces of data and information as we can possibly get out of this binary and that is a really good signature when we when it comes to things like rule writing in yara and sigma these kind of url signatures are going to be invaluable and eventually they'll probably make their way into like an ip block list for lots of different malicious urls but for right now we can keep this as a really good piece of information for something that this piece of malware is doing so we have detonated the malware one time we have observed a little bit about the initial detonation and maybe a few things that happened during that time but now we need to do something very very important at this point you don't know the full scope of what the malware has done right we might have a couple of network signatures we might even have picked up a host-based signature but you're not sure if the malware has installed itself as a registry key or it has installed itself as a scheduled task or it's deleted files or it's added files we don't know any of that so what we have to do now is revert back to our clean known good state and so what we'll do is that we will actually shut this down and we're going to go back to our series of snapshots here and we're going to say we're going to go right back to this basic dynamic pre-detonation we're going to restore this and we don't have to create a snapshot of our current machine state and we'll go ahead and restore and so now that that's back to being the current state we can start up flare vm again and remember it's very important to do this because we got to make sure that we have a clean slate to run the malware from given that it might have changed things in the file system and the operating system that we don't know about yet so at this point we're free to rearm our binary and execute it again and this time we'll use other tools to look at the host based signatures so meet me in the next video and we'll take a look at those all right my analysts now we've talked a little bit about network indicators now let's pivot over to the other half of the coin in basic dynamic analysis which is host based indicators so there are a number of tools that you can use for this and one of the first that i like to go to is a little tool called proc mon you can go ahead and just search proc mon and click on that icon and this is part of the sys internals software suite from microsoft and we will be using the sysinternal suite a lot when it comes to host indicators and it's something i recommend that you try to practice and get really really good with is all of the tools in the system internal suite so we can agree to the end user license agreement and we are given this kind of very busy looking ui now the power of procmon is that it can tell you information about certain processes and what those processes are doing at any given point and sometimes if you couldn't tell from the amount of information on the screen it is a lot to cover and so what i want to introduce you to is the most powerful feature in procmond which is this little filter icon right here so what we want to do is click on the filter icon and we can start to put in filter criteria that will just give us the information that we really want out of this section of the analysis now we don't know a whole lot about this binary but we do know what the process name is going to be and the reason we know that is because it's the name of the file so if we take this process name and we're going to drop down this uh drop-down menu right here and we'll go to the process name which is right here and you can say is and there are a bunch of different criteria you can use so if you don't exactly know it you might be able to do contains but we do know exactly what it is so we're going to set this to is and then you can set this to the name of the file when it detonates which is malware.unknown and then we click add so when we click apply and ok to this the filter criteria will set and now we don't actually see any events yet but that's okay because we haven't detonated this piece of malware yet so what we're going to do is double click and run and pay close attention to what happens here and we can almost see it in chronological order because we can sort by time we can also sort by things like path or operation and so what we really get a good idea of is what the process name is which we already know we also get the the process id which is right here we get the operation what exactly is this process doing and we get the path where in the file system or the operating system is this interaction taking place now the operation column right here is also one of the most important things that we can look at so we can take a filter criteria of operation contains and what if we want to see everything that has to do with files we can say add to files and then we can look at okay we've got create file we've got a query name information file we've got read file and we can expand this path field here and start to take a look at all of the interactions that are taking place so a lot of these are going to be create file or query file from some of the dlls that are loading into the binary when it runs but some of the interactions here can be quite interesting if we take a look at things like well what are the files that are actually being created by this process and if we scroll down far enough we can actually find an indicator that correlates with one thing that we found earlier during our basic static analysis remember that from the strings here we found this file path that is c users public documents and then this kind of random.exe right here so we could actually take that and apply that as a filter and it turns out that that's in here as create file and so if we expand out the details we can see that there was a successful file creation of this file located in c users public documents and then the name well sure enough if we go to the file explorer and we go into that path so c we go to users we go to public and we go to documents well there it is right there so this is another indicator that we've picked up now this definitely wasn't here because there's nothing in the public documents uh directory by default and we can actually test this hypothesis by deleting this file and seeing if it will spawn again if we run the malware again and sure enough it does so we have another indicator here so let's go ahead and take another screenshot and we can kind of set the stage here so that we are highlighting this right here and we're highlighting this right in here and so what we can do is we'll move this down a little bit to get a better screenshot right there and let's go ahead and we will take a screenshot of this and copy this to our clipboard and we'll bring up our notes again and for our host indicators so we'll say host indicators we can paste this screenshot in and maybe resize it a little bit just so that it's a little easier to read we're starting to make progress and unravel what this malware might be capable of now we know that it's reaching out to a particular uri and we know that it creates a file on the desktop somewhere now remember this file that we've created is going to be the standard inet sim executable so remember if we go to like doesn't exist dot com slash evil dot exe remember that inet same is going to serve us up a binary that just says this is the inet sim default gui binary now we can kind of start to hypothesize about what this piece of malware might do if it downloads a file and lands it in the file system from a remote address we might be able to hypothesize that this is like a malware dropper that it's downloading something from another location and dropping it to uh infect the system with a second stage payload so we're not going to know exactly what this payload was unless we're able to go to this particular url and unfortunately we won't be able to do that but maybe on another system that is internet connected we can go see if this is uh serving out something at favicon.ico now something else i want to point out is that this is kind of a little bit of tradecraft the favicon is that tiny little and i'll bring it up for you so you can see the favicon is this tiny little icon that's up here uh that you'll see next to a website uh title in maybe the tab like you see right here so for inet sam it's got this little s-i-m and it's a square now cyber criminals and apts and malicious cyber actors like to abuse this fact because any time you go to a website like this you are inherently requesting the favicon.ico and if it exists it's served up to you so that it can render in the browser right here and if it doesn't exist then nothing happens it's just a 404. so we see something like this that this favicon.ico is being requested but there's something being written to the file system we just don't quite have enough information to correlate these two things so it looks pretty promising to hypothesize that favicon.ico might be the second stage payload it's requesting to this web resource and writing it to the file system so we've got plenty of things to look at now as far as what this malware might be doing so let's move on with more host based indicators all right now let's see if we can get one more host base indicator out of this piece of malware now remember at the beginning i showed you that if inet sim was not running at the time that this malware was detonated it would actually delete itself from disk and i'm sure that there's something that we can drill into to find how that actually takes place so let's take a look at this one right here cmd.exe it's got a ping command it pipes the output to devnull and then it actually does a delete command as well so let's go ahead and take this command and ctrl c and we'll go back over to procmon so when we open up procmon we'll go back to the filters and we'll actually go to the details filter so detail and then we'll do contains and we'll copy in that piece of information that we took out of the strings and we will add this and we can also of course do the process name is and then our piece of malware which for this instance is still malware.unknown.exe so we can take the name of that ctrl c copy and then add that as the criteria again nothing will be showing up in process monitor yet because we have not executed it so remember that the criteria for this piece of malware to delete was to not have inet sim running so we can think that maybe the logical flow of the program might be something like this if this piece of malware detonates and reaches out to a given url and that url does not exist go ahead and stop what you're doing exit out of the program and delete yourself from disk and that can be kind of like a kill switch for a piece of malware where if the c2 domain for the malware is not live anymore just exit out of the program and and don't continue the execution and delete yourself from disk so let's go ahead and see if we can coerce that to happen remember that we have our inet sim box over here is running right now and if we double click on this the actual program will just execute and the program does not delete itself from disk but if we go over here and we ctrl c and kill inet sim we should now have the conditions required to detonate this piece of malware and have it delete itself from disk if we double click on this we see that the command box opens up and if we pay attention to process monitor we should see a call to cmd.exe the binary does delete itself from disk and now we can drill down into the details section of process monitor now this is very interesting because if we open this up the binary called to command.exe to run the very string that we saw earlier in our strings output and it turns out that when you issue this command it will delete itself from disk after pinging for a count of one so that is the mechanism for the self-deletion of this binary and we now have that as a piece of information so again we can take our notes here and we'll bring this to the side and we will take a screenshot of this and we'll put this into our host indicators for our basic dynamic analysis so i have just copied in this screenshot for our host indicator and at this point we can kind of now start to unravel the rest of the program so we can say something like this program execution flow if url exists download favicon dot ico run favicon dot ico ico if i could type if url doesn't exist delete from disk do not run so we have now done a very limited amount of reverse engineering to what this program may look like from a programmatic standpoint we now know that if there is a particular url which remember we identified as this helpdesk pros.local slash favicon.ico if that exists which we simulated via using inet sim as our internet simulation capability then the piece of malware downloads favicon.ico and there's actually another part here writes to disk named and then we have the name up here which is cr433101.dat.exe and we can put that in here as well and then run favicon.ico which on disk now is called cr4 and then there's another case here as well if the url doesn't exist the program stops what it's doing it does not download favicon.ico it deletes itself from disk and that's it so that's our first foray into basic static and basic dynamic analysis we took a piece of malware that we knew absolutely nothing about we pulled some basic information about it we used this basic information to start to look at the different network and host-based signatures and we started to unravel what this program is capable of and now for the rest of the course every time we come up against a new binary that we know nothing about we'll do a similar kind of methodology to start to tease apart what the binary is actually doing and what it's capable of and so that wraps up our first set of basic static and basic dynamic analysis now at this point we might want to call this something else so instead of just a generic malware maybe this is now a dropper and instead of unknown why don't we call this download from url dot exe and now we've more accurately classified what this malware is capable of and what it does all right and that's our first set of basic static and basic dynamic analysis if you're sticking with me so far great job you've you've learned a little bit on how to take a look at these different pieces of malware and how to apply tools to identify what they can do and we're going to go into more depth on different methodologies to identify different pieces of information about these binaries so i'll see you in the next video and we're back all right if you are joining me from the last video we have looked at some of the network signatures for this new unknown binary if you didn't watch that one go ahead and make sure you watch that one first because this is part two in this little series for doing the basic dynamic analysis on this sample so go ahead and watch that one but if you have already watched that one keep on rolling with this one so now begins the game of guessing what this binary could be doing given that we have a couple of key facts so we know that it's made an http request out to a specified server we know that it has downloaded something that has been served up by inet sim but in real life could be some kind of second stage payload but now we don't quite know anything else at this point but we can start to use these as base facts to start to unravel the rest of the capabilities but before we do any of that we have detonated our binary and we should revert back to a clean state so we'll go ahead and do that and i will cut to when the revert has succeeded all right we're back and i have reverted and we'll arm our binary and set it back so that it can be executed so let's take a look at our notes and we have a potential file download we know that inet sim needs to be running or else we'll get this error block and so let's take another look at some of these strings and see what we can determine so if we have a potential network indicator maybe we can start to chase down other host indicators given what we know about how it interacts with the network and so while msd core lib may not be the name of the binary as it's written to disk we also happen to have a file path here and so it looks like app data roaming microsoft windows start menu program startup so the startup directory so commonly used to put in programs to start when someone logs in and a very common vector for malware to abuse now could it be that msd corelib.exe is written to the startup directory that is a hypothesis that we can put together and maybe we can test that now one way that we could do that is using procmon what we can do is go run procmon and agree to the license agreement now we do have the name of our executable so let's go ahead and copy that and we'll go to the filters this little filter icon right here and we'll set this to the process name there it is i was looking for it but is and then we can put in our rat unknown.exe and we hit add and we hit ok now there won't be anything here yet but that's okay we haven't detonated yet and make sure we can double check by going over to our remnux box we can go ahead and stop wireshark we can make sure that inet sim is still up and running and it looks good so remember we're after host-based indicators so we don't need to necessarily worry about wireshark output we've already captured that let's go ahead and double click and run and immediately we've got tons of information here i mean there is just so much going on here to look for but remember that we meet the criteria for detonation so we should not get that pop-up box right we have it connected to a fake internet resource that it's drawing from now we can start to look at the host space indicators and one of the most useful columns of data that we can filter on here is operation operation has things like process start registry key values that are opening closing being read file creation so it also has some information about tcp sockets that are opened up during the detonation of the malware so it can be very interesting to go ahead and filter on the operations here so if you ever wanted to know maybe the different file operations that are going on you can go operation contains and then we can do something like file add this as criteria and now we have in the operations column things like create file query basic information file and it looks like this binary is querying information out of tons of different dlls and that makes sense right lots of different capabilities that a binary might rely on are in different dlls and this is still going to be a lot of information but we can start to cut down on the different things that we're looking for by giving different filter criteria now if you recall there was one string in this binary that could be very telling about what this binary may be doing from a host-based indicator perspective now let's go back to our notes and let's scroll back up to the strings that we have so remember this file path right here the startup directory inside of app data is commonly abused and used by malware to either install itself as persistent or perform something at startup maybe install a second stage payload have it run when someone logs in so this is a very very juicy indicator that we want to latch on to so from our notes we're going to take our app data roaming et cetera et cetera and one of the other very interesting and useful filter criteria here is the path filter and we can add path contains and then we can put in our file path here and click add and so we can actually filter off the operation contains file because we have another criteria that we're testing here and hit ok again if we run this we can see if something happens inside of that file path and it absolutely does now let's take a look at these indicators because this could be one of the key critical pieces of functionality inside of this malware we may have just discovered the persistence mechanism of this piece of malware so let's take a look and analyze so we have ce users husky app data roaming microsoft windows et cetera et cetera et cetera it goes all the way down to startup and that mirrors pretty accurately the string that we pulled out of the binary app data roaming microsoft windows et cetera all the way down to startup now it looks like it can cats right at the app data right here so in other words looks like it doesn't need to know the first part of this full file path it looks like it can dynamically guess okay the user right now is husky and this will be whatever your user is on your box and then it'll say okay in the app data directory drill all the way down to startup for the husky user and we can tell that because there is no c users husky in the strings here it looks like it determines that dynamically all right moving on let's see what it actually does we can expand this details pane right here and there's going to be a lot of information here so let's go ahead and maximize this screen and expand this all the way out and we can even just hover over it to get like a tool tip here so we're looking at the ms core dll.exe right and so it looks like it's using this as the name of the file that it is trying to write to it looks like it's giving right access to this location and it looks like our operation is create file so if you recall we did not make a get request to the server for ms core dll.exe our get request was actually a little bit different msdcorelib.exe but it looks like it may be writing this file to the file system under the name of mscoredll.exe which is weird for a couple reasons right first of all why are you calling something that has a dll in the name an exe this is an executable and this you you would essentially think that this is a dll a dynamic linked library so that doesn't really make a lot of sense also the fact that this is being written into the startup directory in app data is also pretty suspicious so we're going to go ahead and take screenshots of this so go ahead and grab these screenshots this is all very very juicy information that we want to hold on to so we're going to say uh host based indicators and throw that in right here and we've got all kinds of information now to look at here that mscore dll.exe looks like it's pretty pretty suspicious and hey why stop there why don't we actually open up that startup directory and see if it actually wrote something because it says that it succeeded but you never quite know until you check so let's go ahead and grab this we'll copy and we'll just go to any file explorer window and go to the startup directory and sure enough we've got mscore dll.exe if we double click on this remember that this is the inet sim default gui binary it does not perform any malicious functionality but it does represent that something was downloaded from the internet and written to the file system and it's now in the startup directory meaning that if you log out and log back in whatever is sitting right here is going to be executed at the time of login so that is a pretty tried and true persistence mechanism for a piece of malware and that is also something that we want to put in our notes let's go ahead and take a screenshot of that make sure you get the full file path in here we'll copy that to the clipboard and we'll say persistence binary and we will paste in that screenshot excellent information so far so we've got a web request out to a specified server we have a web request download of an executable that executable is named something different from what it was downloaded as and written into the startup directory and all of this is contingent on there being a working internet connection to get to some kind of web resource otherwise we get an error message no soup for you but we're not gonna stop there because there's more to this binary and so we're gonna do another round of analysis but before we do that we should and you know what i'm about to say reset your vm send it right back to the restore current snapshot to whatever your predetonation snapshot was and hit ok and i'll meet you back there alright so we are back out we have rearmed our binary and reverted back to a queen snapshot and for the next set of indicators that we'll get out of this binary i want you to think a little bit about when a host needs to make a connection to some other host how does it think about and know what that connection is right and so the host itself needs to understand the concept of tcp if it's going to make a tcp connection so there are classes of functions that the operating system needs to understand to be able to perform that tcp connection now from the host based perspective we can actually pick up on some of these indicators as tcp artifacts meaning that maybe a socket opens maybe a connection goes out and all of this is coming from the host itself so when we talk about network indicators and host base indicators there really is a certain subset of the host space indicators that have to do with network signatures but they're not quite out live on the wire we can't really pick them up with wireshark they're happening on the host and that's where we should look for them so one of those is going to be an open socket for tcp connections on the host and we're going to use a tool to see this called tcp view now i have installed the sysinternal suite in my program files directory and this was a function of the fact that during the flare installation for this course it did not install the sysinternal suite correctly so i installed it myself and if you do not have the sysinternal suite on your workstation you can grab it right off the microsoft website it's free and it's a very quick download and i've included the instructions for that in another video in this course i'll link it in the resources so go check that out now in any case let's take a look at what tcp view can do so when we open up tcp view we have the window of all of the different types of connections the state that they're in a local address remote address and port itself and this is very important because you can tie this all to a module name and a process name so let's sort by alphabetical order here so we'll click that a couple times and to make it very easy for us we'll just take note of our process name which is rat unknown and we can go ahead and find that when we double click here we should be able to scroll down and it actually helps out by highlighting in green when there's a new connection established but we actually do end up seeing the process name of rat unknown.exe has a couple of tcp protocol events associated with it so let's analyze we've got rat unknown exe is now in a listening state on all addresses that 0.0.0.0 just means don't pick a specific ip address just give me any ip address so it's listing on all addresses at local port 5555 this is a fantastic indicator so let's go ahead and screen cap it and we'll say tcp socket in listening state and there we go all right so we have a socket open in a listening state on port 5555 now we can go over to something that's in the network like our remnux box and we'll go ahead and go to a new tab and we've got this wonderful little tool called netcat which you can invoke with nc and netcat can act as the kind of swiss army knife they call it of networking tcp and udp connections and so now that we have an open socket we have another tool that we can use to interact with this socket and so we will invoke netcat with dash nv for no dns resolution and verbose mode and we will type in the ip address of our remote host in this case which is our flare vm box and the port that is now specified which has opened up on five five five five and it looks like when we make a successful connection we are greeted with what is certainly base64 encoded information now remnux has a base64 utility that's built into the operating system so what we can do is we can take any string of interest that we'd like to decode copy this we can echo this right into the terminal and just paste it in between the two sets of quotation marks and we will pipe this to base 64-d and when we hit enter on that we are greeted with the base64 decoded text which is what command can i run for you alright so we've got a couple more indicators here let's go ahead and take another screenshot of this so we'll go ahead and grab everything on the screen here we'll copy that to our notes by saying base 64 encoded data from socket on tcp 5555 and we'll throw that screenshot right in there what command can i run for you so that's pretty pretty interesting right so let's start to look at the inputs of this open socket now so you can send information like ipconfig and it looks like we've got something in return here so let's say that this is the encoded information so let's take a look at what the decoded information so let's paste this into there and when we base64 decode it looks like yes indeed we have command injection capability from this that is returned in base64 encoded format so again very good to take a screenshot of this because this has confirmed what the initial report said which was that this is likely a command injection or command execution capable remote access trojan we'll say something like command injection capability and we will paste in our screenshot there that proves it and of course we can always kind of resize these if we need to we can go ahead and you know open it up so that's just a little bit easier to read but we have a pretty good indication that this is a remote access trojan it's able to inject with commands and return information by injecting and executing on the file system and we can prove this by maybe doing a few more uh we can do id and we'll go ahead and remove everything from the line and there we go we have the output of the id command which looks like it does indeed run and then maybe something else i'd like to do is just kind of throw in some random text here to see if it handles certain exceptions and we can take the exception here and let's take a look let's delete out our other base64 text and the system cannot find the file specified additional info requested command not found asd asd asd so it does in fact handle those exceptions so this looks like a full-blown command execution remote access trojan it opens up on port 5555 to the file system it has command injection capability and it also looks like it writes something maybe not it writes itself to the startup directory but it does look like it writes something to the startup directory so at this point we've got plenty of information to go off of to say that this is a piece of malware we've got network signatures we've got host-based signatures and at this point we can call this whatever we want so we'll go ahead and call it ratcmd socket.exe.mouse now back over on our flare vm box we do have tcp view up and running here but why don't we combine this with another tool to see if we can start to cross correlate and so we will open up procmon one more time and we'll go to our filter criteria and let's filter for the things that we know at this point we know our process name is going to be rat unknown.exe so we will say contains or it could be is for that matter we'll open that up and then we'll also filter for the operation contains tcp and this kind of does something similar to what tcp view over here is doing but we can get additional information out of this as well so let's go back over to our remnux box and remember we have the open command socket here so let's do the id command we do get a callback from that but let's look at what happens over here we open up the details section here and it looks like we do have a successful tcp receive and a tcp send coming off of process name of rat.unknown.exe so in lieu of something like tcp view we can use procmond to look at the tcp operations which could include send receive maybe the socket opens up let's say let's go ahead and go to task manager and we'll find the rat unknown which should be right around here we'll end this task end process and then if we keep this we can see the tcp disconnect that's another indicator that we have in the tcp operations section and if we double click on this and run this rat one more time we have all kinds of information we've got tcp connect send receive and so this goes to show you that procmon can also be used to filter on these operations super powerful super important to look at the different types of things that the process is doing on the file system and the operating system and now let's take one more pass here let's open up our criteria to be a little more broad so let's uncheck the operation contains tcp and here from the blank process monitor screen we can go ahead and just click the clear button if you have extra information that you don't want remember we're going to start fresh here so let's go back over to remnux let's issue another command let's do who am i and we do get the base64 encoded response here but what's more important is to look over here on the host for this and it looks like we have a lot of information here but it does in fact try to find the who mi.exe binary and so that's interesting as well with this command injection you can actually see the the mechanisms for how the command injection takes place and it looks like it's a straight system execution it looks for maybe a binary that's called that whoimi.exe and in this case it found it inside of system32 and it performs whatever that binary is meant to do and it returns the information by tcp sending it back to the origin for the client that's connected to this command injection server so let's wrap this up at the end of the day what does this really look like when it comes to malware well we can call this a couple things this looks like a remote access trojan it looks like it has command injection capability but remember that it opened up a listening socket on the host that it infected and there's a very specific term for this this is actually a bind shell that looks like it has command injection capability so we have bound port 5555 to the operating system and we say anybody who connects here on port 5555 can issue a command and remember if we open up remnucks over here we can issue a command after we have connected to this port successfully and the command will be executed on the operating system given that we took a look at our process monitor and we found that it will look for something like who am i or maybe it opens up cmd.exe and executes it that way it reads from the output of that execution and it sends it right back to the client that has connected classic bind shell meaning that we have to connect to it first we're able to issue commands to it and the command output is returned to us so we can call this rat unknown we can call this rat bind shell i think you can really call it whatever you want but i'm going to go ahead and call this rat command shell.exe and with our report we can now submit that for additional analysis given that we have performed the triage and the basic dynamic analysis successfully it's a great job there we have looked at a piece of malware that's able to inject execute and return the output of commands on the operating system good stuff all right analysts now we are going to take a look at our new sample for another round of basic dynamic analysis and so i would like you to find the rat.unknown.exe.mals sample which is located in the basic dynamic analysis directory and so first things first we should take a look at some of the text files that have been left in here so let's check out the read me analyst excellent work with the last sample please take a look at the one in this directory our ir team said it might have command execution capability but we're not sure please proceed directly with basic dynamic analysis and determine network signatures space signatures command execution capabilities if any and any other findings from the reverse engineer team okay great so we have our orders so let's take a look we've got the md5 sha-1 and sha-256 hashes already so thank you to the ir team for pulling those so that's one less thing that we have to do and we have the standard password of infected as well all right so why don't we open up our notes to a new section and we're going to call this rat dot unknown dot exe dot mouse and we have our 7-zip file right here so we can drag that right to the desktop open this up we do our standard password of infected and we can open it up and drag the sample right to the desktop now the reverse engineer team has asked us to proceed with dynamic analysis but we will pull the strings and take a look at some of the other static artifacts of this binary just to aid us in that effort so why don't we open up a commander window and on the desktop we're going to run floss.exe and we're going to point it at our sample but i have found that it might be helpful to write the output of foss to a text file so we can uh parse through it and look through it without needing to stay inside of the terminal and so what we can do is write this to floss.txt hit enter on this and it might take a second but it should be going now and we see that floss.txt has appeared on the desktop so just give this a second all right and at the completion of floss we should get our terminal back and we have floss.txt which we can open up we're going to have a lot of useless string information here some of these are just not going to be very helpful but that's okay now do the diligent work of looking through the strings here now eventually if you've scrolled through the strings and you've taken a look you might start to find some things that might look familiar so it looks like we might have uh connection keep alive connection host with some user agent information here and then we start to get some very interesting things we have internet open w internet open url w we have message box w so it looks like these strings are actually making references to windows api calls and so these ones are interesting in particular and we also have some very interesting strings here which look like what command can i run for you online no soup for you uh we've got a nim http client right there so name is a language that malware can be written in so it looks like it's invoking the uh http library and we've got it looks like an executable name here so lots of very interesting strings here so from right about here up i think i'm going to take all of this and put this into our interesting strings section so strings and floss output and we will throw that in there and all of these may be useful when we start to do our dynamic analysis because if you look here we might have a second stage payload executable name it looks like we might even have a url down here so all of this is very helpful and it's stuff that we will want when we go into our basic dynamic analysis section all right excellent so we have taken a look at the strings and of course the point of this portion of the labs is not to focus on static analysis but static analysis is of course very important to be able to get a good read on the indicators that we want to find in dynamic analysis all right so let's go right back to just the open desktop here and we have our rat unknown.exe.mals and of course we can arm this by removing the dot mal's extension and say yes and we have an executable now and so we can now do our initial detonation and triage of this piece of malware so let's go ahead and double click on this and wait and just see what happens alright so that did take a second there but if we just wait for the malware detonation to take place we will have this error box no soup for you all right interesting so that's our first indicator so we can go ahead and take a screenshot of this and we can say that for initial malware detonation we have something that looks like this i posted it twice there but that's okay we'll go ahead and say initial debt and we've got a an interesting message box here that says no soup for you okay like i said there's always more to what meets the eye for this kind of malware so we're going to go ahead and say that the initial detonation looks like it's not going to execute much now there could be something happening in the background here and you're you're never going to quite know from just looking at the malware as it detonates but that's a very good indicator to keep and it also was in our floss output there you remember that we got the string for no soup for you so it looks like we've pinned down part of the execution here is that under some kind of execution conditions a message box pops up and it says no soup for you alright so that's good good to know but what else could be happening behind the scenes here so let's go ahead and play around with a few ideas in the basic dynamic analysis phase we want to get a good read on host-based indicators and we want to get a good read on network-based indicators let's go ahead and make sure that our inet sim box is up and running so that if this malware is going to attempt to call out to the internet it has a place to go so we'll go right back to our pmat remnucks box we'll make sure that's started up and it will restore itself and remember when you're starting up vms and stopping them and suspending them sometimes the networking stacks get a little a little weird with that so all you really need to do is make sure that inet sim is running and then if necessary you can go right back over here to the pmat flare box and just make sure that the dns server is set to the ip address of that inet sim box so we'll go ahead and make sure that we do that right now so let's just ctrl c and stop inet sim and then we can start it back up just to make sure that it's got a nice clean startup and we can go ahead and go back right over to our pmat flare vm box and just remember that we can put in any kind of ip address or url here so google.com should get us to the default inet sim server page and it does excellent alright so we know that upon detonation of rat unknown.exe we have an error box that pops up and we have some kind of activity happening but we're not quite sure and we're going to add in the ability for this piece of malware to reach out to the internet and receive a valid response upon detonation let's go ahead and see if we can coerce this into giving us any more information now remember over here in remnux we also have wireshark that's available to us so let's go ahead and select the correct interface and hit the blue shark fin icon right here to start capturing on that interface and then with both of these things running let's go ahead and run our binary and we can go right back over to remnux and it looks like we've got some interesting information here so we have used the combination of inet sim as well as wireshark to pick up some of this information and it looks like we might have something of interest now it looks like we've got plenty of information as far as tcp packets that are trading back and forth but the first higher protocol that we can find is usually the most interesting one so for example this tcp handshake looks like it is setting up the connection but we also have this this http packet here which is a higher protocol and therefore might have more interesting information for us so i like to go right to the highest possible protocol that can be parsed by wireshark and so it looks like we have a get request out to a uri here http colon slash serv1 dot ec2 102 95 13 2 ubuntu dot local now this is a fantastic indicator right here so i'm gonna before i do anything else i'm going to go ahead and grab a screenshot of this and make sure that i can even open up the image editor here and within the image editor i want to make sure that i draw attention to the different things that are interesting here so we have a potential uri and we have a get request with a very interesting uh user agent if you haven't noticed that go ahead and take a look at that that user agent and i don't know about you but i've never seen one that had that as a valid user agent before so very interesting stuff and there's another thing that's very interesting here here at this http packet it looks like we have a get request for msd corelib.exe and that may be some kind of second stage payload that could be some kind of additional capability and we don't quite know this yet but that's very interesting so let's go ahead and highlight that as well when we have our highlights here we can go ahead and copy to our clipboard and open up our notes and let's say we're doing our wireshark packet analysis and we can go ahead and paste that picture right in and resize it just to make sure that it fits nice and well so when the binary has somewhere on the internet to reach out to and make a request to and by the looks of it it's this uri right here serv1.ec2 etc etc this error message does not pop up and in its place we have a get request to that url plus the msdcorelib.exe binary and again we don't have enough information to make any determinations about what this might be doing but it's very very interesting information to have and it's correlated with some of the strings that we found earlier when we ran floss against the binary it looks like we have a bead on this string that ends up being a url and we also have this string and this string right here so all very interesting information now back in the wireshark output we're going to take a look at a very interesting feature and a very useful one as well that uh wireshark has which is the follow stream feature if you go down you you can right click on any packet in the wireshark capture and go to follow and you might have some different options here you can either follow the tcp stream or you can follow the http stream again i like to try to follow the the higher protocol meaning the one that is higher up in the osi model and so the tcp stream of course would be lower than http and so we might get more readable information more human understandable information out of the http stream so let's go to this get request of msdcorewib.exe and we'll go ahead and right-click go to follow and go to the http stream if we follow this http stream we see that there is a get request to a particular resource on the serv1.ec2 ubuntu local machine and so inet sim responds in turn with its default binary that it serves up and it looks like there was a successful transaction so if this piece of malware was not in an internet simulated network meaning that it doesn't have inet sim to talk to perhaps it would go out to the actual url that is located here and try to download this file and so it looks as if this has been written somewhere on the operating system given that it has successfully downloaded the inet sim default binary and perhaps it's writing it somewhere and that's very important information because that could be a second stage payload or it could be some other kind of capability so it's something that we're going to want to track down now unfortunately there's no guarantee that this is the actual name of the executable on the file system and so what can happen is that a download from a web resource and the writing to disk can be two very separate transactions the data of the download can be transmitted first and then written to the file system with another name so that's actually a common piece of tradecraft among red teamers and cyber criminals it's known as dechaining or decoupling meaning that you download a web resource and write it to disk under a separate name so we have this as a very interesting piece of information we'll go ahead and focus in on this and we'll say potential file download and we'll fill in the msdcorelib.exe all right so we have uncovered some interesting information so let's go ahead and move to the next video in which we continue the basic dynamic analysis of this unknown binary so meet me there all right everybody it's a great day to take down another malware sample and here we are back in flair vm now if you have not done so already always remember to revert your machine back to a clean state before you execute any more malware so this sample will be located in the labs go into the two dot basic dynamic analysis section and this one is rat unknown two unknown2.exe.mals the last one that we did was unknown this one will be unknown to dot exe dot mals now as always we've got a little help in the form of the hashes that we already have here we have the password of infected pretty standard and we've got the readme from the reverse engineer team it says analyst excellent work with the previous samples you are really coming along with your skill set we found another sample on the endpoint that looks similar to the last one give it the triage treatment and let us know what you find alright sounds great guys so we will go ahead and begin by transferring over our sample and we'll bring it onto the desktop with the standard password of infected so we have our sample on the desktop ready for analysis now we will start by doing a limited amount of static analysis and so we will pull the strings and look at the iat of this binary we of course already have the hashes and we could submit this to virustotal if we wanted i have already done so and it does not return any results so it looks like this is a custom fresh sample never seen before in the wild let's open up a commander shell and we'll go ahead and change directories to the desktop and we'll run the floss utility against rat unknown2.exe.mouse and what we want to do for this is pipe this out to flossout.txt hit enter and we're going to let that run for a little bit now as we're about to open up the floss output here and take a look at the strings that we've extracted from the binary i hope at this point we're starting to get into kind of a rhythm or a methodology here where we will take the sample we'll take the hashes if they haven't been provided we can upload it to virustotal and then from there we have a couple of activities that we can do given that this is a portable executable 32-bit or 64-bit for a windows system so um it i hope at this point that we're starting to develop kind of our methodology here now eventually at a certain point when you've been scrolling through this and you're taking a look you will see certain things that identify this as a nim compiled binary uh we have a lot of libraries that are referencing dot name extensions uh we have socket callouts that kind of thing again nothing definitive at this point we're just pulling the strings eventually you may get to the point where you see just a couple of these that are kind of interesting now we have a cmd.exe string in here with the slash c flag which means that it is able to run a command and we've got a dot local here but it really doesn't look like we have any definitive urls or ip addresses or anything like that and there's probably a reason for that and we'll get to that here in a second uh so the strings in this case you can go through and try to find some more information but there's just really not a whole lot going on but that's okay so that's really just one part of the puzzle and if you find yourself getting kind of bogged down and looking at the strings and not being able to determine much of what's going on go ahead and move on to another part of the analysis and remember those those key pointers that i gave at the beginning of the course remember to never get too bogged down in some of the finer details there actually happens to be a reason why there are no ip addresses or urls in this particular sample and that's kind of one of the points is to make sure that not all the answers are going to be immediately available every time you pick a single part of your methodology but it's much more about drawing different threads together and really painting a comprehensive picture now let's load this thing into pe studio all right and we can take a look into the import section and see if we have any on the uh bad bad list over here and there are a couple but nothing really stands out virtual protect might be on might be flagged as kind of suspicious here but virtual protect is used in a lot of legitimate cases as well um now of course this kind of thing comes with experience and you may not know exactly what an api call is at any given point or what it might be doing but i always recommend that you break out the microsoft documentation for each of these calls if you're not familiar with them and through practice and through kind of getting familiar with with what malware looks like and what regular programs look like you'll get kind of a feel of which ones of these api calls are worthy of your scrutiny and which ones are probably okay uh but we can move right over to the strings here and it looks like there's a whole bunch but right off the bat we've got a couple that are probably a little suspicious connect select send classified in the network group so this is going to be kind of your socket open socket close socket send which is effectively a library to be able to work with opening sockets opening a network point of presence so that you can send and receive data on a network and we've got our socket call out right here in string form but in any case again when we look at the strings here when we look at the indicators that are coming out of pe studio we don't see a whole lot going on so why don't we move right on to our dynamic analysis and what we'll do for our dynamic analysis always remember that we're going to have remnucks running in the background over here and let's just have inet sim up and running and we'll also have wireshark running as well so we can capture all of that good network traffic we've already kind of deduced that there is a socket capability here so we want to be on high alert given that there might be some kind of network indicators coming off of this binary all right so let's arm up and always a good time to double check that you have a good snapshot to revert back to just in case and we're going to go ahead and run as administrator and let's move right over to our remnux box and let's see what happens and it's it seems to be scrolling a little bit but we do in fact have some information here and we've got dns queries coming out let's take a look and if we open the highest protocol here which is our our dns protocol we can open up the queries section and it looks like we've got an a record looking for aaaaaaa.kadusis.local okay excellent now if you recall in the strings of the binary if you looked thoroughly enough you would not be able to find any of these you might have found caduceus you might have found local but you would not have been able to find all of these and the reason for that there's actually a couple reasons for that here i employed a common malware tactic where the strings are built at runtime during the binaries execution instead of compiled so in other words there are some times when a malware sample will have the url kind of hard coded in the in the code itself as a variable maybe the string variable is uh domain name equals and then it is you know free t-shirts dot info or something like that or in this case aaa dot caduceus.local but there's a way to break up the string so that it cannot be assembled unless the binary is actually running and so when you see these a's here this is actually concatenated at runtime so it goes through basically a for loop and it says okay add a until you hit i think there are 20 here total and then when you have that pass that into this full domain record here and then that is going to be your domain for call out always be on the lookout for that this kind of goes to show you that the domain names the ip addresses usernames passwords that kind of stuff skilled malware authors will not always hard code those into the binaries that you're examining in fact more often than not they're not going to be in there but always keep a lookout because there are still other indicators that you can find in this case we had to go to dynamic analysis to be able to pull out this domain record so now that we have a domain record what can we do with this well i think the first thing that we want to do is let's get our notes going here and we're going to call this rat.unknown2.exe.mouse and of course we could have had our static notes in here but we're in the dynamic analysis section at this point so i'll just be recording notes for that but i do encourage you to record all of your notes that you're taking in this and so what we can do is take a quick screenshot here so let's grab a green shot screenshot and we'll actually get the hex dump as well why not copy to the clipboard and we'll throw this in we'll say dynamic analysis throw that picture in there and of course we can resize this to make it a little bit easier to see and so we have an a record uh dns of uh a and i'll just do dot dot i think there are about 20 of those dot caduceus local okay fantastic notice that there's no http there's no even tcp at this point um there's no other indicator of any other network traffic going on we really have a dns callout and then nothing else we have some icmp that fails right uh because it's looking for that um so that's definitely interesting because if there was kind of an http if there was a web request opening up we'd probably see that and then that would fail if there was nothing to respond to it but it looks like this one is just looking for an uh a dns record so i want to show you guys a technique that i have come up with in instances where you are getting a domain call out or maybe an http request and it's effectively it's pretty similar to keeping inet sim up and running but instead of sending it to another box we're actually going to send it to ourselves now this binary right here has a value in it that says i am trying to reach aaaaaaaa dot caduceus.local now what is stopping us from saying oh caduceus.local is the box you're on right here and one way that we can do that is by using the hosts file which is a very simple thing to do but it's actually good enough to trick the malware into thinking that it is connecting to its home base server so what we want to do here is we're going to search for commander but we're going to open it as administrator because what we want to do is edit the etsy hosts file on this system so we'll do nano which is built into flare vm by default and we'll do c windows system 32 drivers etsy and hosts and you can of course tab auto complete and we'll launch into nano for the etsy hosts file now this is exactly the same as the etsy host file on linux so you can specify an ip address and then specify a domain record of where that ip address will send and the local host will read from this file first before it attempts to resolve any other dns records and so what we want to do in order to trick the binary into thinking that whatever it's looking for is on the host that it's currently on we're gonna punch in 127.0.0.1 and just hit some spacebars until you get to in line with the other ones here although it doesn't really matter but i like to keep things nice and clean and we'll go right back over to our wireshark capture and open it up down to the queries section here and down into this aaa caduceus local and of course you can click on the name field right here which is the d has the value of the dns record we'll click copy and we'll do the value right here so just click copy and value and that's going to copy in that aaa dot caduceus.local we'll head right back over to flair and we can just right click right in here inside of the terminal and that will uh paste it in so we have our record pointing at localhost127001 in order to save this in nano we're going to hit control hold down control and hit o it's going to say file name to write and you can just keep it standard it's a system 32 drivers etsy host keep that standard it will say wrote 22 lines when you hit enter there so again that is hold down control and hit o so just like that and then you can just hit enter and then to exit out of nano you're going to do basically the same thing hold down control and hit x and we're back alright so now at this point this binary is going to attempt to call out to that resource that domain record and if we have something on this host that's going to be able to respond to that traffic we're effectively tricking the binary into thinking that it's talking to its home based server when instead it's talking to us so nifty little trick pretty simple it's effectively the same thing of what inet sim and and some of the other internet simulation uh capabilities are doing all right so we're starting to unravel the puzzle here but we do kind of have a problem we do know that it's attempting to reach a dns record but remember as i said the wireshark output does not really have any other information it says that it's pointing at a dns record but it does not say a port uh it does not say any kind of protocol so we we've got a problem we don't really know how this is trying to connect to that dns record now what from the host can help us out with determining what that might be why not procmon why don't we open up procmon and you see how we're kind of starting to build out a methodology here and i've already done so but you can open up the filters here and we've done this a couple times so you should be uh pretty good at this now we've got process name is rat unknown2.exe and we've also got operation contains tcp and we want to make sure that we're catching any network traffic from the host level that we can find on this so we'll go ahead and hit ok for this we've got nothing in procmon's output because we have not executed the binary at this point so let's go ahead and run and there we go we've got some call outs here and immediately we can actually determine what's going on if we look at the path column right here and it looks like we've got from local to aaa caduceus.local on https so we can now take that and let's go ahead and write in our notes we'll definitely take a screenshot of this and we're going to bring this right to our notes and say potential call out to specified dns record on https port 443 and that is four four three again we don't know that for sure but we do have a protocol that supports that from the call out after we detonated the binary while looking at it in procmon so we've combined a couple of tools at this point to try to pinpoint what this binary is doing so at this point because the binary thinks that its home plate server is us let's go ahead and open up our netcat we'll dash nvlp and we'll give it 443 given that the binary is attempting to call out on https so let's see what we have and it looks like we do have a successful connection here and we have in procmond a tcp connect and we can take a look at the details here and it looks like yes this did in fact succeed we now have an open socket to our home plate server which we've tricked the binary into thinking is us so at this point what else can we do to determine more information well remember that this is rat.unknown2.exe so it's likely that this has some kind of command injection capability but if you didn't know that if this was just unknown.exe now that we have an open socket here what do you think would be some of the first things that you would do to determine what this binary was doing i know that i would absolutely throw in a who am i and see if i get any anything back and it might not be immediately but you did just see the flash there and it looks like we're getting some more information back here we've got a couple more connects we've got a tcp receive a tcp send and then we've got an output of desktop slash husky so let's take a step back and think about what we have on our hands here where the first binary that we looked at that was similar to this was a bind shell it looks like we have the other half of the coin here which is a reverse shell in other words we have set up a listener and when the binary was executed it reached out to the listener it connected to the listener and it opened up a command shell and now we can input commands like id we look in the background here and look at that how cool is that we see it actually happening and boom it's got our uh output right here alright so we've got pretty good indicators right now again screenshot screenshot screenshot let's take another one right here and we will say reverse shell capabilities and we'll throw the screenshot in there and we can resize that a little bit there we go perfect all right so so far so good we've got a bead on our reverse shell capabilities of rat unknown2.exe now meet me in the next video and we're going to continue the dynamic analysis and we're going to take a look at a very interesting concept that's very pertinent to malware analysis looking at the parent and child process relationships that are going on inside of this binary so meet me there and check it out all right we'll pick right back up from where we left off this is part two of the reverse shell so we're working with rat unknown two dot exe so make sure if you haven't seen part one go check that out first uh but if you have keep on rolling with this one and we'll pick it up right where we left off all right so so far so good we've got a bead on our reverse shell capabilities of rat unknown2.exe so why don't we clear this out and we'll take a look at the filters and let's broaden our search again so let's take out tcp and click ok and let's just throw in another command let's do id and we should get something pretty similar to what we saw with the bind shell again this is going to be we've got our tcp receive and remember that the receive and send is going to wrap this whole all everything else that's going on with this binary the tcp send and receive are going to wrap those and it looks like again it goes kind of down the list it tries to find something in the current working directory that it can execute and if not if it doesn't find anything there it goes to system32 and it does find command.exe now i want to take this time to talk about something that is super super important when it comes to defenders taking a look at processes and really even from a red team perspective this is also very important for operations as well and this binary is a really good example of the concept that i'm about to talk about so procmon has a really awesome feature right here called the process tree and let's go ahead and open up the process tree so from explorer.exe we want to go down a couple processes and find our rat.unknown2.exe right here so this is our parent process of our actual malware but there's something i want to point out here this process is actually in turn a child process of explorer.exe if you're not familiar with explorer you've probably uh at some point in your life gone to task manager and opened up details and maybe you've gone to explorer.exe and done this and then your friend maybe if you did this and and pranked them they probably were freaking out a little bit but of course you can always just type in explorer.exe and start one up again and it's all good so what was the point of that little thing um your explorer.exe process is the process that spawns all of the other interactive things that you can do on a windows system so this is like the big parent process of all of the kind of interactive stuff that you can work with now let's take a look at procmond procman is actually a child process of this explorer.exe so in procmond anything that proc mon has going on for it inside of the operating system it will be tied to this parent process by uh pid right here so often in logs you'll see something like ppid which is parent process id of 2768 which would be explorer.exe so when we talk about malware there's always like i said more to malware than meets the eye rat.unknown2.exe has a process id of nine two four but if you see these kind of grayed out images here at certain points during the execution of our program remember that if we went back over to our main program over here let's do like an ipconfig right so what will happen here is that the main process of rat unknown2.exe is going to spawn a new process as its child and that child process is going to be cmd.exe in this case now what's interesting is that you can see the arguments of that child command down here in the process tree and so you can see cmd.exe is called for id right there now this happens for all of the other times that we have executed something from this binary so the idea is that rat unknown2.exe is the parent process and is spawning these other child processes for cmd.exe if you've ever seen some of those very expensive very high-end endpoint detection response uh products and i won't name any here but you can you probably know what i'm talking about something they do really really well is they graph out in visual form the parent processes the child processes and they identify if any of them are out of line or seem kind of weird so in other words if you have an unknown executable that's spawning cmd.exe and that in turn is spawning all manner of commands like id or who am i or ipconfig somewhere along the line you've got to say some of this is is pretty suspicious and that's kind of the idea of parent-child process relationships and so skilled malware authors will try to break or de-chain also known as decoupling this parent-child process relationship as often as they can and there are many ways to do that which we'll get into a little bit later in the course uh for right now remember that the malware that we're dealing with is quite naive it's quite um built not to be sophisticated to be better for an entry-level analyst to be able to study but at some point we will get to some of the more sophisticated malware but for right now just know that the process tree in procmond is a really good way to see from the main binary that's detonated here what other types of information can we get out of it as far as child processes and what those child processes are doing now the other thing to note here is that you won't be able to really see much of that information by just filtering off the processname rat.unknown2.exe so what we can do is go to parentpid right here and we'll put in the pid for the rat unknown.exe process which is 924 and we'll add that in and click ok now we'll filter on anything that has rat unknown2.exe as its parent process and when we do that we actually get a whole bunch of other processes that are under it and we've got all our calls to cmd.exe here and we can actually just pick out a few of them here we've got our ipconfig looks like it queried and found ipconfig in system 32 and was able to do that and so that is the idea so remember to filter not just for the name of the executable of what you're detonating but remember to pick up the process id of the main executable and set it to the parent pid which is right here when you set it to the parent pid it will pick up any child process that's coming off of the main one and that can be super revealing as far as what the malware is doing at any given point hey everybody it's husky here i hope that you're enjoying this five hour release of practical malware analysis and triage on youtube we're more than halfway through the course look at you go congratulations on that and hey right now would be a good time to take a break stretch out go for a walk drink a nice big glass of water or maybe call a friend and tell them how much they mean to you and hey while i have you remember that the full release of this course is still available on tcm security academy and if you want four more hours of advanced malware analysis techniques and specialty malware classes then you can go right to the link that you see on the screen right now and purchase the course and if you use my affiliate link i get a little bit more of the profit and i thank you for that anyway we're almost done with our intermission here so please enjoy this nice little boss in overtune and i'll see you back in the course [Music] [Music] [Music] all right my analysts i hope you're ready for a challenge today it is now time for the first challenge binary in this course which is challenge number one silly putty which is available in the main labs directory go to 1-3 challenge silly putty and just to set up the scenario it looks like you're getting a binary from the ir team who is saying that this is a program used by the i.t admins at the corporation and they've been using it and they had no problems until recently but it looks like now it is popping up weird blue windows and crashing sometimes so they think that there might be something going on with it and they want you to take a look at it now the way this challenge is going to go take a look at the objective we're going to do static and dynamic analysis on this sample and extract some facts about this malware's behavior and then we're going to answer the challenge questions that are down here at the bottom and of course these are the tools that we are using that we have learned so far in the basic static and basic dynamic portions of this course so take a look at these questions these are the ones that we'll be answering for this scenario crank up your favorite lo-fi chill beats to dissect malware 2 and have at it and try to make it as far as you can but if you get stuck remember that the answers directory has a readme file with the answers for this challenge but as i said try to get as far as you possibly can without using that first so go ahead and open up to the main lab repo go into labs and right down here 1-3 challenge silly putty we'll go ahead and open that up and right in here is going to be your challenge binary in this password protected 7-zip file have a great time get after it and don't forget that the answers are right here if you get stuck so good luck all right analysts i hope that you enjoyed that challenge i hope that you were able to answer at least some of the questions and also i hope that you were able to answer them all um and regardless of if you were able to answer all of them or none of them hey even just getting in the ring getting in there and taking a look at these binaries and seeing how to you know pick them apart and figure out how they work you know that's commendable so great job on that now if you're joining me from the previous video this is going to be the walkthrough for the first challenge in the course which is silly putty and i'm going to be following along with the questions that have been provided uh so just follow along with those and we'll start there so one of the first things that we need to do is get the sha-256 some hash so we'll go over to the desktop and just to do this one i'm going to stay right in the terminal and launch a powershell instance all right so from a powershell prompt i'm actually going to use the hash getfilehash.com and we'll pass it the algorithm parameter and the algorithm in this case will be sha256 and we can tab autocomplete that and then we pass it what we're trying to hash which is the putty.exe binary and so we do have the sha 256 hash and we can pull that and submit that as the first answer the second question what is the architecture of this binary among other tools one that we can go to to get that answer pretty quickly is we could go right down to utilities and we can open up pe studio and pe studio is actually going to have a lot of this information as well so we could just load in putty.exe into pe studio we actually could get the sha-256 right there as well but we do see that this is a 32-bit executable as identified by pe studio great now if we were to submit this to virustotal at the time of recording this i did not receive any results from virustotal for the sha256 sum uh that may change as the course goes on if this hash becomes known that it is a piece of malware in the course uh it's likely that that is going to change as well but for right now there are no results so we will be moving on describe the results of pulling the strings from this binary so this was intentionally made a little more not necessarily difficult but this pulling the strings out of this binary was a little less helpful in this instance than it usually is and i'll explain why here in a second all right so if we exit out of that powershell prompt and go right back to the regular commander prompt we can go back to the desktop i'm going to use the floss utility but i'm going to actually pass it an argument of dash n and i did not cover this in the course but the dash n argument is actually very powerful and it will try to cut down on any strings that are of size n or less so in other words if you want a minimum string length of 8 you'll pass in n8 and then we'll throw the executable name in there for putty.exe always a good idea to output this to floss.txt for the output because it is a lot of information and just let that run for a little while because this is a rather large binary and there are lots of strings inside of it this may take a long time so while we let that run if we go back over to pe studio there should be a strings section in here and again there are lots of strings in here but we can take a look and we can also sort it by the block list here and we can take a look at some of the strings and see if we can pick anything out in particular but the reason that this was a little bit more difficult than it's been in the rest of the course is that well this is putty.exe this is not just some kind of like dropper program or a very very small malware program if this has been provided to us because it's been suspected to be malware it appears that this is probably a backdoored program i.e a program that has legitimate functionality putty.exe but has some kind of malicious backdoor installed in it as well and so if we pull the strings from this we are really pulling the strings from the binary itself and that includes all of the other strings that are associated with the binary's normal operations and so we can look through the strings of this but it's very difficult to pick out something that could be malicious out of that unless we look very very hard i did this intentionally it's a very good skill to have as an analyst and a triager to not get sucked into one particular part of a methodology and not beholden to a very rigid set of methodologies so i threw you a slight slight curveball with this one i hope you don't mind i hope you were able to kind of think through it and reason through it but in any case when we do have the strings output we can look through it but there's not a whole lot going on and even later once you have completed this challenge and you look back with the strings that you're able to find there's really not a whole lot of correlation to be had so maybe no luck on the strings output that could be a dead end or if there is some information in here there's just too much to sort through there's too much to try to figure out so there's got to be better ways to ascertain our information and as an analyst it's a very critical skill to understand when the time is right to move away from one part of a methodology in favor of another one now if we look at the imports we could either use pe view or pe studio which we're already in here and we can go right over to the imports and sort by the block list here again and again we suffer kind of from the same problem now there are lots of different apis that are imported in this in this program and putty makes use of a lot of these different apis for its intended actual functionality so it may be tempting to say delete file a or reg key create reg key delete oh that must be malicious and even though pe studio identifies it on the block list that doesn't necessarily mean that it is in fact malicious i know for a fact that if you put your credentials into putty and it saves them it actually saves them in the registry now whether that's opsec safe or not that's another discussion but the legitimate functionality of the program makes use of these imports and the same thing can be said for map view of file and write file and shell execute a all of these look like they may be malicious but in fact are part of the normal functionality of putty and that's another point to consider that as an analyst if if someone comes to you with a program or an executable or a script that they think is malicious you'll have to make the determination if those parts of that program are in fact malicious or not and that can be very difficult to determine so as for an iet analysis we're still kind of stuck in the same place that we were when we pulled the strings and that is to say there may be some information in here but it's just too much to kind of effectively sort through so the real long and short of it is that the static analysis of this challenge binary gets us a little bit of information but really not enough to go off of and so one of the most important parts is that moving to the basic dynamic analysis of this binary is very very important to be able to tell what it's actually doing so we'll close out of all this we'll get right back to our desktop and we will start our basic dynamic analysis portion of the questions so the first question asks us to describe the initial detonation and so if we double click on putty we in fact do get the normal putty window here and ostensibly we could put in anything we want we could do 127.0.0.1 on port 22 and try to open that up and it looks like putty is actually functioning as normal and of course there's no listening ssh on the local host so it's going to fail but it looks like this is just putty as it regularly operates but if you double click this again you do see it flash for just a moment there you do see that there was a blue window that appears as well if you read the readme of the challenge binary that was one of the details that was mentioned to you by the ir team and so that is probably something that we want to investigate so let's start there after initial detonation we have a blue window that pops up and just normal putty so we can annotate that now from the host space indicator perspective what is the main payload that is initiated at detonation and what tools can you use to identify this so with the blue window that pops up we can maybe take a couple of guesses as to what that might be and one thing that comes to mind is maybe that's powershell.exe powershell.exe opens with a blue window by default and so what we can do is go to procmon so we will open up procmon and i'll bring it right down here and remember we know the name of the executable so we have something that we can filter on just reset if there are any filter criteria in there and we'll go ahead and do process name contains putty now let's go ahead and run this and we will get a whole bunch of results but at this point we do have a process id for putty.exe so why don't we take that process id and filter on that as well and we'll use that as the parent pid so the parent pit in this case in my case is 4716 so i'll put in 4716 and i will add that as criteria and then we'll have to filter off the process name because putty is not going to be its own parent process but when we filter off that we actually have the for the very first thing that we can see here is probably one of the most interesting parts of this entire analysis and what we have is a gigantic powershell one-liner we see powershell running from the command line with a hidden window and a non-interactive window it's bypassing the execution policy and if we go into this one more time we can actually pull out the script block that it's using and i'll make this a little bit bigger so we can see it a little bit more powershell is creating a new object to be able to handle a gzip stream so that's commonly used in file compression now one thing we can do is we can take this whole block copy the whole thing and we'll have to clean it up a little bit so it might be a little bit easier to maneuver around in something like codewriter here and we can just clean this up so we can parse it out we have the powershell.exe right here and then this is where the script block starts and what we can do is see this gigantic base64 string which is converted from base64 and given to the compression object and so one thing that we can do is grab this entire thing all the way down to the two equal signs that's down here and we'll ctrl c copy that and we can go over to remnux and we will do an echo with two quotes we'll throw that base64 blob right into the echo here and we'll do two things here we will pipe this to base64-d and we're going to redirect that to a file and we don't quite know what that file type is going to be but remember that we saw the compression object so we we assume that it's going to be some kind of compressed file like a zip file or a 7-zip and so if we use the file utility against out we see that it's a gzip compressed data so why don't we open up the file browser on remnux and we find out right here and we can do extract here and if we open this up we actually get the full plain text decompressed and decoded version of the payload that's running when this payload spawns and this can be incredibly telling so this is kind of like a bonus because now i didn't quite teach all of that in the course but it just goes to show you that there's always going to be more data available to you than maybe you initially think so that's just a neat little thing that you can do don't worry if you didn't find that treat that kind of like a bonus and now you know you can take the base64 encoded version of that and decompress it and write it to a file and you have the full plain text of the download and execute cradle that is used in this but let's say you did not make it that far so to answer that question you can say that the main payload at detonation is a powershell one-liner that is running some kind of base64 encoded and compressed payload and remember it's always okay to say i don't quite know what this is doing but we do have that as a data point now it's always okay to say i found this and i'm not sure what it's doing i need to research it more so just as an aside there so we need to figure out the dns record that is queried at detonation and so what we can do for that is we can break out something like wireshark and make sure that we have wireshark up and running there are also host based indicators that we can use for this one as well and let's exit out of all of our putty sessions and one more time we will open up the putty session and see if we can get any kind of information off the dns queries and in fact we do we have this dns standard query to a text record of bonus two and let me open this up so we can see it easier bonus two dot corporate bonus application dot local now this does not resolve at this point because we don't have inet sim up and running and we don't have any kind of handler and response to this dns request so what we would need to do is we'll head right over to inet sim we can get rid of that momentarily and we can fire up i net sim fire that up and of course always you're going to want to check to make sure that your internet simulation capability is up and running so type in google.com and you should get to the default init sim page now that we have set up the internet simulation capability this dns record should resolve to something and we're not quite sure what it's going to do at this point but we're going to go ahead and run this one more time and let's see let's scroll down a little bit more and see if we can find some of the tcp traffic associated with it so from following the initial request and response from dns to bonus to corporate bonusapplication.local we then have some tcp back and forth and depending on how many times you've done this you may see something in wireshark that's a little unique to setting up malware labs in general you may see some spurious re-transmissions this essentially means that wireshark has seen these packets before and is going to drop them and treat them like they are not pertinent what is still very interesting here is the port number and so this is communicating from ostensibly an ephemeral port somewhere and it's going to eight four four three so we can imagine this may be our callback port and to check that we can take a look at something like tcp view and so we will open up tcp view and so if you filter on powershell and you run it you do have to look pretty quickly but there is in fact a powershell going to remote port 8443 right there and it did just disappear now if you missed that you can just do that a couple different times and that it will repeat its results so powershell is sending a request to the remote port of 8443 so it appears like this is setting up some kind of remote communication and we're not quite sure what that might be so we do have the dns record and the callback port number at detonation now the callback protocol is in fact https the interesting thing about this is that we won't be able to initiate a callback with this payload because we don't have an x509 certification to be able to answer and respond to the client hello coming from the tls transaction we could in fact try to do that same trick that we've done before in which we'll open up a commander prompt we'll run it as administrator and we'll drill all the way down to the hosts file and change the host file to the local host so i'm just going to do that real quick and then fast forward to when that is done all right so i have set that up that the bonus two dot corporate bonus application dot local is pointing at the local host and we'll save and we'll exit out of the host file and for good measure i'm going to do an ipconfig slash flush dns to flush out the dns cache now if we stop wireshark and start it up one more time now we will stop wireshark and now all pertinent traffic is going to be headed to the np cap loopback adapter so go ahead and stop the listening session of wireshark that you were doing and go over to the npcap loopback adapter and if we run this one more time we should then see response and request coming from the host so that's good now the second part of our little trick here to trick the binary into connecting to us was to host an ncat session on the listening port so nvlp8443 in this instance which we know from these transmission requests and the unfortunate thing is that if we fire this up and we launch putty and we try to initiate a callback we're going to get garbled junk now why does this happen so if we take a look at the wireshark output we actually see why this takes place the first thing that happens is a tcp initiate connect and which is responded with the tls client hello now this is the first part of the tls handshake and it sets up the certificates that are used to encrypt communication during tls and https now unless we have a legitimate tls certification to be able to present when this happens we will not be able to complete this transaction so what we could do is try to do a who am i here or something like that but that's not going to work and so try as we might unless we happen to have a tls certification on hand we probably will not be able to get a true reverse shell spawned on our local host so unfortunately that is the case but we can in fact take this as an indicator as well as put it in the report and that wraps up the silly putty challenge the final thing that i would want to say is that the way that i created this was actually via metasploit and so if you happen to have a kali linux machine on you and can put it into the lab environment i will leave it as an exercise to the viewer to find the metasploit module that i used for this and try to actually spawn a reverse shell that will connect when you use this putty.exe what you're going to need is a little bit of the host file manipulation to send it to cali what you need to do is study the type of powershell reverse shell that's used here and set up something in metasploit to catch that shell and spawn it and so i will leave it as an exercise to the viewer good luck with that if you so choose to do it but if you decide not to do that fantastic job with the challenge i hope that you learned something and we're able to put your skills to the test so great job and we're going to move on to the advanced sections of static and dynamic analysis in this course so hang on tight because here goes nothing meet me in the next video and i'll see you there all right my friends now we have come to this point in the course in which we are talking about the most technical of the subjects that we will cover in this course we are talking about advanced analysis now i want to start this off right before we get any further it's worth mentioning that this is probably the most technical subject that we will be covering in this course how this subject relates to malware analysis but even how it relates to cyber security and even computer science in general there is so much to this topic that you can spend your entire career getting really really good at the very specific things that are covered by this and now i want to make sure that we measure this and scope this well because my intention for this course is not to make you the absolute master ninja of the world when it comes to advanced analysis assembly debugging decompiling and all of that what i want to set out to do in this course is provide an introduction that is well measured for the beginner audience and so no course on malware analysis would be complete without some amount of information about advanced analysis but my intention is not to inundate you with information and make it frustrating to learn these concepts what i want to do is keep this practical i want to keep it well scoped and i want you to walk away with a few key concepts and key skills that i think will lay the foundation for you to study more about this part of the field so with that out of the way what are we talking about when we say advanced analysis well again like we had in the basic analysis phase we have two major parts to advanced analysis we have static and dynamic now the methods for these phases of analysis are what separate them from the basic static and basic dynamic analysis phases in the advanced static analysis we will of course not be running the binary as identified by the static nomenclature but the tools and methodologies that we'll be using are very different from the basic phase when we are performing advanced static analysis and for this course we will be looking specifically at the windows operating system and windows portable executables what we're really looking at is the assembly instructions of a malicious program azim and we will be loading malware into special programs called decompilers and disassemblers and so we will start with the packaged compiled program that is given to us by the malware author and because malware authors are never kind enough to give us the source code of their applications we will use special programs to reverse engineer these compiled executables and recreate something that will look very close to their original source code and that is advanced static analysis we will be looking at the assembly instructions of an executable and loading it into a decompiler and a disassembler to extract insight about how this program was written and its logical execution flow now on the dynamic side dynamic analysis of course means that we will be running the binary but the way that we'll be running the binary is very special we will be loading this into a debugger now the important thing about a debugger in the context of malware analysis is that when we load the binary in it allows us complete control over the execution instructions and so debuggers are actually used for lots of different things if you are a software engineer you'll use a debugger to see how your program executes and maybe find problems and and issues in it and of course that's why it's called a debugger but for a malware analysis perspective we're going to be using the debugger to investigate how the program executes and have complete control over every single instruction that's executed and between these two phases we will uncover all kinds of information about how this binary was built how the logical program flow is executed and what this binary can do so before we begin let's talk briefly about what assembly instructions actually are and this may be one of the most important concepts to understand when we get into the advanced analysis phase and the way i like to think about this is that there are different levels of computer languages there are things that humans understand and there are things that computers understand up here in the human realm we have the high level languages these are things that humans are familiar with like c c plus plus python other kinds of languages that have evolved over the years to be human readable now unless you've been coding in something like c and c plus plus for a while perhaps those don't really seem very readable when we look at examples of them they seem very cryptic and hard to understand but they're actually very abstracted now when we talk about abstraction what we mean is that there are very primitive instructions and programming languages that happen down here at the low level things that are happening on the bare metal of the central processing unit and so abstraction is the idea that humans don't really want to work with all these ones and zeros all day so they take patterns of zeros and ones and they bring them up a level and they say okay instead of a bunch of zeros and ones that i have to code right on the bare metal of the operating system because who wants to do that i'm going to write these very very low level instructions like move jump xor and those instructions are going to represent the different patterns of these ones and zeros so that i could write a program in this and the computer can understand it but i can work with it a little more effectively now as time went on we took these lower level languages and abstracted them up and up and up and up until we finally had things that looked like human language main print hello world now to us that looks a lot more readable than move jump xor and a bunch of ones and zeros and so that is the concept of abstraction in action now when we think about the assembly language what the malware author will start with is the high-level source code so they will write a main program and they will write a method that does do evil stuff and the program will be written to do whatever the malware is designed to do when the malware author wants to package that up into a program that can be double clicked and executed by the central processing unit they will use a specific piece of software called a compiler now the compiler will take this human language syntax up here and it will say all right i understand both the human side of this programming language and i know how to translate that to something that the computer will understand as well so what it does is it takes these human words up here and it translates them into patterns of bits and bytes that the computer can understand and so when the operating system wants to execute this program the compiler is the thing that has put the human language into form that the processor will understand so when a program is compiled it is brought from a high-level language all the way down into the lowest possible level language that there is now where does assembly come into this so assembly think of it as one level of abstraction up from the lowest possible language so assembly lives right about here and assembly language is the human readable cpu instruction set now what does that mean so instead of kind of ones and zeros and bits and bytes that are all the way down here on the bare metal of the cpu the assembly language will take the patterns of those bits and bytes and translate them into just a little bit more human readable form and so assembly languages look a little bit more like this move e d x e a x and we'll talk about what that means here in a bit test e a x e a x and then maybe something like j and e and then maybe like a memory location now this may seem a little cryptic at first and admittedly this is kind of the crux of the issue when it comes to teaching assembly is that it can be very cryptic and kind of difficult to understand but what i will say is that language precedes understanding the more that you kind of work with assembly the more you'll start to be able to sight read and manipulate these kinds of instructions but the point is not to understand assembly right now the point is that assembly lives somewhere between high level languages and the lowest possible level languages and more importantly for malware analysis when we are given an executable that's nice and packed up like this box malware author is going to leave us a nice packaged executable that just has a bunch of cpu instructions and we will not really be able to understand those but what we can do is use a disassembler and translate those instructions into things that we can understand now i think that's enough explanation for right now so let's move into the lab and we'll actually see what this looks like from a practical standpoint all right so we've been talking a lot of theory a little too much theory if you ask me let's get practical here so i'd like you to open up to the lab section go ahead and find the 2-1 advanced static analysis and we'll be working with this first program right here dropper.downloadfromurl.exe.mals now if dropper.download from url seems familiar that's because it is if we open up the readme hi analyst this is a sample from earlier your initial analysis identified that this binary has the capability to download a file from a remote host and copy it to the file system open this sample up in a decompiler disassembler and take a closer look make sure to pay attention to the api calls and how they're being performed so to start our advanced static analysis we're actually revisiting a binary from earlier in the course if we go back to the labs and we go back up to the basic static analysis one of the first ones that we worked with was this malware.unknown.exe.mals right here and so this is the exact same sample and i wanted to provide something that you'd be familiar with remember that this binary will take a url as an argument and it will attempt to reach out to a website and if something is there then it will execute and if something is not there it will delete itself from disk with that having been said let's use this as the first example of our advanced static analysis we can bring this right out to the desktop and we don't actually need to arm this what we will be doing is going to a program called cutter c-u-t-t-e-r you can go ahead and search for that in the start menu and so i've already opened it up here but you probably will not have that so once cutter opens up you can go to the select button right here and navigate to your desktop and find the sample that we'll be working with dropper.downloadfromurl.exe.mals once that has been selected we can go ahead and open this we will keep the analysis to enabled and keep it at the auto analysis or aaa level we don't need to do any advanced options and we'll hit ok now the first thing that you'll see when you open up cutter is the dashboard and the dashboard will have a lot of familiar information it will identify the architecture of the executable it will identify some other things that we've already found the md5 sum and the sha 1 and shaw 256 hashes and so there's lots of useful information here but it's nothing that we haven't really already seen now where the disassembler slash d compiler shines is over here we have a list of all of the called functions that are in the program and so what we'll do is we'll double click on the entry point and we will be brought to this screen now i know that this looks very busy and if you're looking at this and it looks like a foreign language well i mean it really is at this point if you don't know what you're looking at you're looking right now at the innards of an executable program this is assembly language it's the closest you can get to the metal of the cpu without being an actual electrical signal which is super fascinating to me and one of the things i love about assembly as kind of cryptic and and hard to understand as it is there's nothing to hide when you write and read an assembly there's no abstraction layers that somebody can hide behind this is the absolute truth of what's going on on the operating system when a program is called now this is some fascinating stuff but i don't think we're quite at the level that we can really understand what's going on here but what i want to do is talk a little bit about how a program is executed so when a program is written there will be a central function called the main function and that's the function or method from which all other functions or methods are run and the disassembler will identify where that main function is and so if we double click on that we can actually find where in the program per the assembly instructions where the main function is located and now we're starting to kind of get acquainted with how to use a disassembler and read what's going on in here because remember if you remember that binary from the the early phases of basic static analysis we actually start to see some things that are familiar so we see an instruction to push a string right here and see user's public documents and then cr433101.exe if you recall your notes from the basic static analysis portion when we looked at this program during basic static analysis remember that this is actually writing something to that location and it's interesting that it shows up in the disassembled output as a string so again this information can be pretty cryptic and hard to understand so i'd like to introduce you to my favorite feature in this tool which is the graph function and the graph function is incredibly helpful because it kind of graphs out the logical flow of the program now recall from the basic static analysis example remember that this program tries to connect to a specified web url and if that connection takes place it will download something from that url and store it in the c user's public directory and then run that process and on the other side of that if the program tries to reach out to that url and there's nothing there it will just delete itself from disk and so we don't even have to understand a whole lot about assembly yet to understand that that's exactly what's happening here from the main function and so we see some strings that we identify we see that ssl dot data manager help desk bros.local to favicon.ico that is stored in the binary as a string somewhere that string gets brought out to be used and then it will call the api function of url downloads a file remember that this was the very api that we saw in the body of the program during static analysis and then the results of that call are actually loaded into a special place in the memory of the computer called the eax the extended accumulator register and we'll go a little more in depth on that when we get to the advanced dynamic analysis but in any case it tests the contents of this location of memory and then if the contents are one thing it will jump to a location in memory and if the contents are another thing it'll jump to another location now we read this as jump if not equal and then a memory location and we see that the memory location number right here matches exactly the next graph block on the graph so recall that we observe the download from url function if it returns something as valid it would execute the rest of the program and if it didn't return something as valid it would delete itself from disk and we can follow that because if we test the contents of this memory register and it's not zero it will go one way and if it is zero it will go another way and so without getting too far in the weeds with all of these instructions and what they mean this is a really good way to visualize how a program is executing and go to the graph representation of how these instructions are actually functioning because these instructions are the very very low level very primitive representation of the kind of just big moving parts of the program we will attempt to access a web url and if we are able to access that web url we will execute the rest of the program and if not we will delete ourselves from disk and so this is the principal use of a decompiler disassembler it tells us a lot of information about how the program is executed from the very low assembly level so right now we're in the graph representation of the main method but if we go down here to the decompiler the d compiler will take the assembly information of this binary and attempt to recreate as close to the original source code as possible and remember that's just a function of the fact that the assembly is a further abstraction of the lowest possible level of the machine code so what's stopping us from taking that assembly information and extrapolating it up to what could be the original source code or at least something similar and again there's a lot of information here but we can start to pick out strings and bits of information that look interesting so if we see this url download to file w is the actual direct api call that we're making to this ssl that manager help deskpros.localfavicon.ico so that is the exact parameter that's passed to the url download to file api call and we're able to recreate what's close to the original source code of the application now i'll leave it as an exercise to the viewer look around a little bit more in this application and see if you can find some of the strings that we pulled from the basic static analysis let's see if you can find some of the urls that you found in the basic dynamic analysis and then let's see if you can trace into this program from the main method right here and see just the couple of function calls that can be called from the main method when you look into that so go ahead and give that a shot and meet me in the next video all right now if you're joining me from the last video we just took a look we loaded up a binary into cutter and we took a look at kind of the inside the innards of the binary and looked at a bunch of cryptic things that you know maybe we didn't understand while we were looking at them and that's okay this part of the course is all about building pattern recognition right so the more that you work with assembly at the at the low level the more you'll start to see patterns and the more you'll start to see things and say hey i recognize that i know what that does now i want to cover a few of the x86 instructions and things at the assembly level that will be very important to understand this is not going to be an exhaustive list by any means but i do hope to clarify just a couple of the things that we might be looking at when we take a look at the inside of a binary like that all right so for a binary to execute in the x86 architectures there are really three things and this is a bit of a simplification but there are really three things that we need to think about for any of this to take place in the first place we have the cpu instructions we have the memory registers and down here we have the stack and perhaps you've heard of one or two or maybe even three of these so we're going to cover briefly what these are and what they do and then i'm going to show you in a practical sense uh what they kind of look like at the assembly level all right so first things first left side cpu instructions like i've said before when you write a high level language and you say if something like this happens do something like this and that's how the program executes when the compiler translates that into something that the cpu can understand it needs to be translated into cpu instructions from a high level there are about three types of cpu instructions that we will cover there are arithmetic instructions like subtract there are data movement instructions like move and then there are control flow instructions like jump so let's take a look at some of these so we have things like m o v j m p and then s u b move jump sub so those kind of represent the three different types of instructions in the instruction set now the x86 architecture is little endian which means that data is written unintuitively from the right to the left and so when you take a look at an instruction in the x86 architecture the instruction is going to come first and then the destination is going to be the next thing so when you see something like move e d x comma e a x think that the instruction comes first the source comes third and the destination comes second so it's a little bit out of order it's a little strange so it's something you kind of have to get used to that it's move eax into edx not move edx into eax and we'll talk about what eax and edx are here in a second all right so we've got a movement instruction so if you want to move data around while the binary is running you'll use something like the movement instruction now the jump instruction is a bit like if you need the program to jump to a certain location or another one so this is very useful in logical branching so a jump instruction might live right about here and it will say jump to and then it will have a memory location right here and so if something happens if there is a conditional that is met you can use the jump instruction to go to one part of the program or another part of the program now there are several iterations of the jump instruction and there are ways that the jump instruction will function so we can look at something like a j n z instruction which we read as jump if not zero and so this happens a lot in returning true or false values and so we will go to one part of the program if the value is zero meaning that the thing that we are looking at returned true or if the value is false which would return a one so if it's zero go this way and if it's one go this way so jump if not zero now the arithmetic operations work pretty much exactly how you would imagine them to work you can subtract numbers from other numbers you could even subtract locations in memory from a certain memory location we'll talk a little bit more about that when we get to the stack portion now there are also some very important instructions here in the way of push and pop now push and pop are how we interact with the stack so the stack is a special place in memory that is kind of like a place that you can hold information while you need to access that information quickly so it has been said that the stack grows downwards so the stack will be assigned a certain location in memory and the top of the stack is going to be the highest possible location and as the stack grows it grows downward so as things are added to the stack they are added to lower addresses so let's say that we want to call a function and we need to set up the variables of that function we will use the push instruction to take those variables and put them here into the stack so we will push 0 we will push a string and we will push the number 12. and so we will push those onto the stack and then there will be memory assignments that have zero that have the string that we pushed and we'll have the number 12. now notice how the stack is growing downward so the first variable that gets assigned to the stack is assigned to the highest possible location on the stack and then every other variable that gets pushed onto the stack is assigned a lower memory address now in reverse we have the pop instruction now once we are done with whatever we're doing on the stack with these variables we can pop them off of the stack and so if we pop the stack we remove the lowest part of the stack that has a piece of information on it and then we can pop pop pop to get these variables off of the stack and return the stack to the way that it was before we move those variables onto it and finally i'd like to cover the call and the ret instructions call and ret so the call and the ret instructions are super important when we talk about the subroutines and functions that the program runs now let's think about how this works with the special method that we already covered the main method every other function in the program is going to be called from the main method so we start at the main method and we trace into the different functions in the program so we had a function that was check url and so we will call the check url function so we will call check url from the main method and the check url function will do whatever it was designed to do and then it will return and tells the world what it came up with as a result so if we think about the main method as kind of like this arrow that's moving forward when the main method starts it will set up a bunch of variables and then it will call a function and the function will do something and return to the main method and then the main method kind of resumes from right where it left off all right so how about a metaphor for this all right so let's say that i have decided that i'm going to sit down and start recording and i'm super excited and super focused about it so the husky program has entered its main method so we're going to start up here main and we're rolling we're having a good time we're writing course material but then my partner emily comes in and she says hey can you go to the store and pick up a dozen eggs so right here at this point when i break from the main method i have called the pick up eggs function and so she has told me hey pick up a dozen eggs and so i will pass in the 12 argument into pick up eggs now that's important because that argument needs to go somewhere so when the pickup eggs function is called that variable of 12 for how many eggs i need to pick up is moved on to the stack so we've got a stack over here and we have put 12 onto the top of the stack so i say okay great so i go out to the store and i'm about to pick up some eggs so i'm going here and i'm traveling to the store but right about here while i'm passing the store i look up and i see that there is a cat in a tree all right so at this point i am actually going to break from the pickup eggs routine and i'm going to call another routine of save cat from tree and so actually i will break from this routine and go into another routine and at this point i am now two routines in from the main call and so i always have to keep track of what i was doing before i split out to do the other part of the function so while i'm saving the cat i don't forget the fact that i'm out to actually pick up eggs in the first place and so i need to be able to go back to wherever that pickup eggs function is once i'm done with the save cat from tree function and the way i do that is i save the location of pickup eggs in the e b p the extended base pointer and so i will say okay because i need to know how to get back to pick up eggs i will save the location of pickup eggs in the extended base pointer and i'll return to that once i'm done saving the cat from the tree so let's say that i saved the cat from the tree and all is right in the world and once i'm done with saving the cat from the tree i will return to the pickup eggs function right here and then i go to the store i pick up the eggs i bring them back home and then i am back into the main method and once i resume in the main method i can continue to do whatever else i needed to do and now the final thing that i want to talk about here are the memory registers now i want you to think the memory registers a little bit like this now i am a child of the 90s so this is a good metaphor for me but if you're not familiar with what you're looking at that i just drew don't worry about it this is a vcr tape so a vcr tape was back in the old days how you would watch a movie or something like that and so the vcr tape had this kind of ribbon on the inside of it and the ribbon represented all of the data of the movie with the audio and the video that needed to be put onto the screen for you to watch the movie and so when i was a kid i would like grab the ribbon from the inside and like pull it out and like you know it would it would kind of spiral out like this um so the point is that there was tons of data written onto this ribbon and it was kind of this continual stream the two little gears in the center here would rotate and there was a little thing right in the middle of the vcr right here called the read head so what was the read head's job well as the ribbon of the vcr moved over the read head which we can visualize kind of like this it would take and remember there's tons of data in here there's audio and visual and stuff so as the tape moved this way over the read head the read head's job was to take the data that was on the magnetic tape and actually display it to the video and so i want you to think of the memory registers a little bit like this read head there are a bunch of memory registers and all of them serve different purposes but they all hold and handle different parts of the data in the binary at runtime now let's cover the important ones we've already mentioned a few of them we have the e a x which is the accumulator register the e d x which is the data register the e b x which is the base register and then the e s p the extended stack pointer the e b p the extended base pointer and then the e i p the extended instruction pointer and now those of you that are familiar with how to perform a buffer overflow may recognize a few of these if you don't recognize these don't worry about it at any given point these memory registers have a reading in them of a particular memory address or location or value or something like that and so the interaction between the cpu instructions and the stack is facilitated by these memory registers if you want to have an instruction executed it will be read in by the memory registers and then brought onto the stack if need be so that was a bit of a crash course in assembly instructions and what happens at the low level when a program executes now this is all a lot of information if you didn't quite latch onto it first don't worry about it this stuff takes time remember as i said at the outset of this video this is all about pattern recognition so the more that you work with this the more that you'll start to recognize these patterns as they occur alright so let's get back into the lab and we will take a look at what this looks like in the technical sense all right and we're back in the labs now remember we are inside cutter and we have opened up dropper.downloadfromurl.exe now we opened this up before and i want to just revisit this because now that we have some of the terms clarified maybe we can start to unravel some of the functionality when we look at the assembly level instructions of this binary and again the point here is not to walk away having known every single little piece bit and byte of this program remember to just take the key functionality away we don't need to get lost in the minutia here we just need to see the big moving parts and i hope now that we've covered the assembly cpu instructions the stack and the memory registers some of this should make a little bit more sense so if you have not done so already go back to the main function so you can search for main down here in the search bar and click on the main function and if you're in the disassembly output go ahead and move over to the graph of the main function alright so follow with me we're going to step through the main function as we see it in the assembly the first thing that we see is that int main with int arg c char star argv and char envp now this is super cryptic and if you don't code in c you might not know what this is but when you set up the main method the main method is always past two arguments implicitly the arg for count arg c and the arg for vector are v and so what this means is that if there are any arguments to pass into the program at start they need somewhere to be passed so they're passed into main and arg c is the count the number of the arguments so this could be like if there's like an argument for source and destination argc could be two and then the arg v is the strings themselves that are passed in as arguments so that is the setup of that we have a whole bunch of variables that are declared that we don't necessarily know what they are at this point remember we're reverse engineering we don't have all of the source code in front of us so when we see variables like this we might not care a lot to know what they are right at the start we just might have to unravel it and see where they go now we push remember the push instruction we push the value of the extended base pointer onto the stack and remember that if we ever want to get back to the main function let's say that we call a bunch of other functions from the main function if we ever want to get back we need to have the value of the base pointer because if we don't have the value of the base pointer we won't know where to return to after we're out of each of those other functions so we push the value of the base pointer onto the stack and say let's go ahead and save that so that we know where to return to next we do a few other things we move the value of the stack pointer to be the new base pointer and when you see this push ebp move esp into ebp this is a very common setup for calling a function you're gonna see that a lot when you see that calling convention and you start to recognize it you're going to start to see it everywhere so just understand that this push ebp move esp into ebp is just a way to set up a function call now we do some other stuff that we don't necessarily care about at this point but then we get to this right here we're going to push push push push push push 0 push 0 push 0 push 0 push string mozilla 5.0 hmm interesting okay so after all of these are pushed to the stack and we might not necessarily know what these are yet we have a call to the d word of internet open w and this is an api call now recall from the basic static portion when we looked at this binary that this internet open w is an api call that you're asking the operating system hey i would actually like to see if there is a resource at this internet address so what you need to do for that is pass it in some api parameters one of those parameters is going to be the user agent which we see right here as string.mozilla 5.0 and cutter actually does us a favor if we want to go see where that is in the program it gives us the memory offset location right here and so we can actually copy that and take a look at that but for right now understand that we are calling the api call and having passed in these parameters now remember if you don't remember how that function actually operates all we need to do is google it but let's take a look at something here how many arguments are pushed onto the stack right before this api call is made one two three four five now let's take the documentation of internet open a the api call and let's see how many arguments are passed in one two three four five interesting so we have a perfect match up of the amount of data that's pushed onto the stack and the amount of arguments that need to be passed into the api call for it to take place and notice how only one of these has an actual value the rest of these are zero but the first one right here is lpsz agent or the user agent pointer to the null terminated string that specifies the name of the application or entity calling the win inet functions we see this a lot in network traffic when you see like a browser that's opening up to a web page and the browser user agent will say hello i am mozilla 5.0 or i am google chrome now one thing to notice is how these variables are pushed in we have zero zero zero zero string mozilla 5.0 but over here in the parameters we have the user agent and then access type proxy proxy bypass and flags and so the point that i'm making here is that the arguments to the api call are actually pushed in reverse so the first one goes in last and the last one goes in first and this is known as an lifo a last in first out system and the stack works as an lifo system remember that things are pushed onto the stack and then more things are pushed onto the stack and then they have to be popped off of the stack in reverse order to return all right so we have reverse engineered our first api call that we have in this program we have five arguments that are passed in pushed onto the stack and then the api call is called next up we're going to do some more movement of variables and then we call to this function right here now we can double click to actually step into this function this is getting a little more down in the weeds from what we probably want to do so let's actually use the back button here and we're going to just hang on to this for a second we call some kind of function and then we push more arguments onto the stack now the first string that we see here is one of the arguments that's passed in as the path to see user's public documents and then the name of the executable that's downloaded from the url and then the next argument that we see is actually the place that it's downloaded from and remember just like we saw up here when we have one two three four five and then a call to an api we have the parameters pushed onto the stack and then a call to an api url download to file w and so this api call is making use of the arguments that have been pushed onto the stack to execute and remember in this case we are downloading something from a url finally we test the contents of eax against itself and we jump if not equal j and e and remember how we specified that the jump is going to take us to one location or the other and so that's a roll up we've revisited the first call that comes off of the main function in dropper.downloadfromurl.exe i hope that clarified a few things so the first thing we did was we looked in this and we didn't necessarily know a lot what was going on we covered some of these terms and then we just reviewed some of the functionality of the program after covering some of the assembly instructions and conventions and again just to reiterate this is always all about pattern recognition the more that you work with assembly you're going to identify these little bits and bytes that look familiar and the more you're going to build out that knowledge so i think that's good for where we want to leave it for download from url.exe we're going to move on to the next video in which we're going to take a look at a process injector at the assembly level and see if we can identify some of the big moving parts of that program as well so meet me in the next video and we'll cover that all right analysts we are continuing with our advanced static analysis now let's go ahead and move over to the 2-1 advanced static analysis lab and we're going to go into malware.stagex0.exe.net and let's take a look at the readme real quick analyst we got one take a look at the sample in the zip folder it's definitely a dropper program but we need you to break out the decompiler and debugger and take a closer look we know that it's trying to spawn a reverse shell and we got to call back successfully to our fake listener but we're wondering how it's actually working to do that exactly anything you can find will help us determine how it got here and how it works the ir slash re team okay fantastic so we'll put that to the side and so in the lab directory we're going to go to 2-1 advanced static analysis and we've already worked with dropper download from url so we're going to go into malware.stage0.exe.mals and in here we of course have the sha-256 sum and the password.txt and the readme as well alright so what we want to do is open this up and we'll put in our standard password of infected and we'll bring this right out to the desktop now of course we want to do our full round of basic analysis before we get into the disassembly and decompilation of this binary so what we're gonna do we're gonna pause the video right here and i want you to do a full round of basic analysis and find as many iocs of this program as you can possibly find and then once you're done with that resume the video and i'll pick up from the end of the basic static and basic dynamic portion and we will use those iocs to perform the follow-on advanced static analysis so go ahead and pause the video right here and we'll pick it back up right here after we complete our basic round of analysis so pause the video here all right analysts we are back and we are going to cover the indicators of compromise and some of the data points from the initial phase of basic analysis for malware.stage0.exe and so i would like to say if you didn't find these indicators that's okay we're going to cover them right now but just make sure that you go back and take a good look at your methodology and make sure that you're doing all the correct things from earlier in the course the fundamentals are still very important from here on out because the fundamentals and what we find in the basic analysis phase is really going to inform how we perform the advanced analysis phases as well but in any case what do we find about malware.stagex0.exe so there are two principal indicators of compromise that we probably want to track down with this piece of malware now the first one comes in the form and we'll just move this right up here the first one comes in the form of a file that is written to the file system that wasn't there in the first place when we run malware.stage0.exe there is another executable that looks like it's unpacked from the first binary which is where fault.exe that's w-e-r-f-l-t dot exe now the second indicator that we pick up and we'll have to look at tcp view real fast to see this one is that where fault w-e-r-f-a-u-l-t actually spawns an open connection for a brief moment on remote port 8443 on the local host so it's opening up a connection or at least attempting to open up a connection on the local host on port 8443 and that was w-e-r-f-a-u-l-t so where f-a-u-l-t dot exe so if we run this one more time we might be able to see that and there is the connection right there from where fault.exe on the localhost so that begs the question what is where fault this one right here and then what is this one right here which looks to be like a misspelling of where fault so the actual program w-e-r-f-a-u-l-t is actually a built-in binary in windows and generally when you have errors in a program where fault will pop up and it will say would you like to send more information to microsoft about this so if your computer crashes or some kind of exception is hit where fault will collect information about that and can be used for further debugging purposes but this right here is not where fault.exe there's a misspelling here and this is unpacked from the original binary that we run so if we run this one more time it appears at runtime so lots of interesting information because we have a network signature something's trying to connect to the local host on port 8443 and then we have a host base indicator of a file that's unpacked at runtime so what we want to do now is we'll take this wirefold.exe we'll move that right out to the desktop and we're going to perform advanced static analysis on this so let's open up cutter again so we will search for cutter and open this up and then we will open up and go to the desktop directory and we'll load in wherefault.exe and leave all of this default we'll do the standard level of analysis for this binary and we'll open this up in cutter now we are immediately brought to the entry point you may be on the disassembler at this point but of course go right over to the graph view for maybe a bit of an easier view and so what we need to do is step through this program and identify the key characteristics of what this might be doing now remember that when the operating system hands control of execution over to the binary it will always start at the main function so all of the interesting parts of this binary are going to be located from the main function and any functions that take place off of the main function and so when we inspect what we see in the main function during the advanced static analysis phase what we come up with is actually the classic pattern for a create remote thread process injection so let's break this down now process injection is a common ttp for malicious actors and effectively what happens is that they will be able to open up another process that's running on the host and inject code right into that process and have that code run inside the process as if it was part of that program in the first place and this is a common evasion technique because the code that runs inside the process has all of the attributes and metadata and lives inside of that process in the first place and so it's very common to see shell code for like a c2 agent or a reverse shell being injected into another process and that's a way that it can hide out and mask itself from detection now truth be told today create remote thread is not very stealthy and that's because the defenders over time have adapted to look for it but when we open up the main function of werefaults.exe we see that this is the classic pattern for a create remote thread injection so let's step through it and see if we can identify some key characteristics here now as we step through this always remember to keep it light keep it moving and don't get too bogged down in some of the details so of course with the main method we're going to have some arguments passed in so pay attention to the arg underscore ch because this does come into play and in fact at one point in kind of the preamble here it's moved into the register eax so we'll keep that in mind we go through a little bit of the preamble here and then eventually we get to a call to the d word open process now this is an api call so let's we can actually hover over this right inside of cutter and take a look so when we look at the open process api call there are one two three parameters here and remember that the three things that are pushed onto the stack right before that are going to be the three parameters that are used by the api call so from start to finish there is a value of 1x ffff which is the desired access level one argument before that let's check we have the inherit handle or not and we are not inheriting a handle from the parent process because this is a boolean value of zero which means it is false and then the final one here and if we hover over that again the final one here is a d word process id and that is the contents of eax now where did we see eax before it turns out that the value of arg ch is passed into eax so you see right here move d word arg ch into e a x move dword rch into eax and then down here eax is pushed onto the stack and so what does this mean we are opening a process and the parameters we're passing in are saying give me all access to this process and the process id is going to be the argument passed into main so argch ends up being the process id and so as we move down we then get to the move eax into edi instruction now remember that eax was the process id of the thing that is passed into main up here as rch now basically this program is given a process id it loads it into eax it uses that to open up access to the specified process that's been given as an argument and then it takes that same process id and loads it into the edi register now it's basically just holding on to that in the edi register for right now because it's about to use it again and that's going to be in the virtual allocx api call so if we hover over this we'll take a look and we see that there is the first parameter that's passed in is the h process the handle to the process well basically what we're doing is giving it the number of the pid that we used in the open process phase so we are requesting the handle to a process to open it up to be able to access it and do things inside of it and then we're giving that to an api call that's going to allocate memory inside of that process now let's keep going and we're going to move to our next api call and work backwards from what we see so we have another api call of write process memory and what do we need for this the first parameter that we need is the handle to the process which is the one that we've been using this whole time which was passed in remember at the start of the program we need a base address we need the size of the buffer and we need the number of bytes written so let's take a look we look at edi which has the contents of the process handle remember that in eax we had the process id and we're just loading that right into edi right here and then we use it again in this api call the esi has the base address of this process and the eax has something very special it's got the lp buffer and if we count we have one two three arguments from the top and that's one two three arguments is going to be the lp buffer now what in this case is the buffer so we have to scroll up a little bit to find that because that's set up a little bit earlier but now we might understand what this could actually be doing and so that's set up as a variable at the very very top of the program so what does all this mean well let's rewind a little bit we are opening up a process which is specified by the argument that's passed into main we are allocating an area of memory inside of this process with the rights to be able to write into that memory we are actually taking those bytes from the lp buffer variable and writing them into that process in the section of memory that we've allocated and the next api call here is going to be the grand finale of create remote thread and so if we go down to create remote thread we see that it does have a bunch of parameters being passed into the api but there are really only two if you look at the instructions here there are really only two that are actually pushed onto the stack for work so that is the first parameter and the second third fourth parameter so one and four are the ones that we want to look at so let's hover over create remote thread and the first parameter is the handle to the process which we've been working for so the second third and fourth is going to be the start address so the start address is going to be where this thread begins its execution and so the value that's in esi currently is what we need to look at because that's what this is actually going to be executing if we click on this it highlights where esi was last used so we trace up a little bit and we find push esi was used during the write process memory section and this actually ends up being the base address of what was written into the process so what we're saying is when you create a remote thread you're going to create a thread inside of a remote process and i do that by handing it to you from the arguments of the main function and you're going to go to the contents of esi right now which is the lp base address so the base address of the data that i've written in during the virtual alloc x and write process memory api calls and so when all is said and done what is the real bottom line of what we're doing here we start by handing this program a process id it takes that process id and it opens up that process with the level of access required to actually be able to write into that process it then allocates a section of memory with read write execute permissions it then writes the contents of a specified variable into the allocated memory and finally it starts a thread in that remote process and tells the thread go to this address which is the address that we allocated during the write process memory call and execute whatever is there and so what ends up happening is that this is a common way for shell code to be injected into a remote process because you can write your shell code into the body of the program and then copy those bytes into the remote process write them into memory and then execute them with a new thread via the create remote thread api so we'll actually minimize cutter here and now i want to show this with one of the really really powerful tools that we can use during dynamic analysis we're going to go down here and look up process hacker 2 and so just type in process hacker 2 and i'll show you kind of how this works in real time so remember that where fault.exe is calling out to the local host on port 8443 so we can open up a commander prompt and we'll get a netcat listener up and running with nvlp8443 so we will listen on all interfaces for 8443 and take a careful look at process hacker move this down a little bit and watch what happens when we execute this program we will execute the program and immediately where fault.exe is spawned in a suspended state so while that spawns in a suspended state the rest of the program is kicked off the pid of wherefault.exe which in this case was 4000 is handed back to the unpacked program werefolt.edu and so when wordfault is executed it takes the process id of wherefault.exe which is 4000 and let's follow along it opens the process up by passing it in the process handle of 4000 and then it allocates an area of memory inside of that process it writes the bytes of the shell code that it's using into that process and then it creates a remote thread and executes the shell code and we get a reverse shell back so if we go over to process hacker and we open up this where fault this is a completely legitimate completely normal application but if we go right up here to the memory tab let's go ahead and see if we can find our area of allocated memory now remember i said when this area of memory is allocated it's allocated with full read write executable permissions and that's going to be very out of the normal for a process like where fault.exe so if we go up to the protection column here and we sort this twice we can sort by all of the different types of protection and usually they're going to be read execute permissions because that's like the normal operation to have an area of memory just have read and execute sometimes they're read write just to make sure that you can move data in and out of memory as needed but there is one in here sneaky sneaky that's read write execute and if we go into the read write executable section of where fault.exe we see the bytes of our shellcode have been written into this process so what i've highlighted right there in the hex output is the actual bytes of the shell code and when this is run in memory by the remote thread it spawns the reverse shell over here now this is getting a little more on the dynamic analysis side but i think it illustrates the idea of this create remote thread pattern of api calls that we just saw in the static analysis over in cutter so i'd like to just take some time to take a look at this and so that's it that is what a basic create remote thread process injector looks like from an assembly level and if you followed along with me thank you and great job that's a super interesting thing to be able to look at at the assembly level is a process injector in action all right and that is our module on advanced static analysis now we're going to move into the advanced dynamic analysis section of this with all of the knowledge that we've accumulated with the previous section and we're going to look at how we can combine all of the different streams of information and tools that we've been using during the advanced dynamic analysis portion so meet me in the next video hey analyst all right we're back and we will be finishing up our four phases of analysis section with the final part here we're going to put it all together with advanced dynamic analysis now the principal difference between advanced dynamic and advanced static analysis is that we will be running the program that we're analyzing but we will be running it inside of a very special program this program is called a debugger and the debuggers that are built into flare vm are available when you go to the flare directory right here second folder down from the top is debuggers and we can open that one up and we have a few to choose from and we will be working with these two at the bottom here for this course we'll be working with x32 debug and x64 debug so let's go ahead and open up to x32 debug and just get comfortable inside of the debugger terminal so if we maximize this we can actually just kind of resize the screens here and we don't have any information in here yet but once we load a program into this debugger there will be plenty of information to look at one thing i would like to point out is that if we go up to options we can go to theme and they do in fact have a dark mode and that's what i will be working with and you can also go up to options and look at the appearance settings and if you go over to font you can actually make the fonts a little bit bigger and i'll do that for you guys so it's a little bit easier to read and there we go so we still don't have anything in the debugger yet but let's talk a little bit about what a debugger actually does so when a program is run remember that when you double click on an executable the operating system says hey we need to execute this program let's hand control flow over to this program starting at its entry point and have that program perform all of the remember at this point machine code instructions uh that are required to run the program and then return control back over to the operating system now that's what happens when you just double click a program to run it now when you load it into a debugger a debugger acts as a broker between you the end user and the operating system while a program is running and so in other words you will be able to have complete control over every single instruction that is actually completed while you are debugging a program now debuggers are not used just in malware reverse engineering they are also used in software engineering as well and so a debugger can be very helpful to step through the source code of your program and see where your variables end up and and maybe find some problems uh with the control flow execution but we are not doing that with source code we're doing that with the assembly instructions of a program so let's actually go to the lab directory we'll open up to labs and we'll go down to advanced dynamic analysis and wouldn't you know it we're using dropper download from url.exe this is the same exact sample that we used in basic analysis and the same exact sample that we used in advanced static analysis and we're going to finally build on all of the knowledge that we accumulated with that and debug this piece of malware we put in our standard password of infected and we can bring this right to the desktop so we are ready to go so we'll go ahead and maximize the debugger we go up to file and we're going to go to open and then navigate to the desktop and we'll switch down to all files remember that we have not armed this yet so we still have the mlz extension and we will double click on that and even though it has the malz extension if you load this into a debugger the debugger will know how to work with it alright so there's definitely a lot going on here and this can look a little bit scary but we're actually well primed to understand what we're looking at here because we went through the advanced static analysis section so over here on the left side we have the cpu window and the cpu window has all of the instructions that are available in the program and if you remember from the cutter section this looks a whole lot like the disassembled output from cutter and in a lot of ways that's exactly what it is it is the assembly instructions that the program will execute now over here on the right this is different we didn't see this in cutter but this is probably one of the most important parts of a debugger and the program these are the memory registers remember that in our advanced static analysis section we talked about how the memory registers are a little bit like the read head of a vcr player and so they will have a reading of the program's memory locations at any given point during execution and we see a few of the ones that are important here we have eax ebx ecx edx we've got the ebp the esp and then right down here we have the eip the extended instruction pointer and so if you're not familiar with the extended instruction pointer this is going to be the memory location of every instruction that's going to be executed next while we're running our debugger so this is the thing that points to the instructions and says go ahead operating system execute those instructions and tell me what happened so it's super important to follow the eip now down here on the bottom right we have the stack and so any value that's pushed or popped from or to the stack is going to be represented here in the stack as a memory location and the contents of that memory so we will watch the stack grow and shrink as the program executes and then down here in the bottom left we have the hex dump output we're not going to use the hex dump so much we're really going to focus on the other three sections first all right so control of the debugger let's talk a little bit about how we move around inside of a debugger we really have just a couple of controls to consider when we're using the debugger they're going to be the f keys so you're going to use f2 f7 f8 f9 and if you go up to the debug section we'll actually get a readout of what these f keys do so f9 is going to be run if you run your program it will execute as if the operating system is executing the program f7 is step into f8 is step over we will talk about the difference between those two here in a bit and f2 is going to be a very very helpful instruction which will set a break point and we'll talk a little bit about what break points are here in a moment so let's go ahead and just run the program hit f9 once and we will see down here at the bottom paused in three break point entry break point at dropper download from url exe entry point so with one press of f9 we have entered the entry point of this program so we are sitting where the operating system will enter into this program and say okay go ahead and execute these instructions and now if we were not in a debugger at this point the operating system would go ahead and just continue to execute those instructions but because we're in a debugger we are now at the point where we can control the exact instructions that are going to run when this program is run now this is a bit of a one-way street because as you execute the instructions you can go forward in a debugger but you can't exactly go back you can't go back to the instruction that you just ran unfortunately so think of this like a one-way street if we hit f8 just one time we move down to the next instructions now notice on the left-hand side that the e-i-p is noting where we are in the execution flow of the program and it's telling us what's happening inside of these instructions for this instruction we are jumping to a memory location dropper download from url and if we open this up a little bit more we see that we are jumping to f7146f f7146f if we hit f8 one more time we see that we have actually moved to f7146 in the memory location of the program and now we are pushing 14 onto the stack so let's hit f8 one more time and we see down here in the stack we have pushed 14 really 1 4 onto the stack all right excellent so we see how this is going we can hit f8 we execute instructions that are in front of us and then whatever happens to those instructions is reflected in the outputs of either the memory registers or the stack itself now we're about to get to a call instruction so let's go hit f8 one more time and where now our eip is resting on this call instruction if we hit f8 one more time we will step over this call instruction and that means step into the program execute everything this part of the program is doing and return me right back out so we can hover over this and see what is actually accomplished during this call but if we hit f8 we don't step into the program to see what it's doing we step over it we allow the debugger to assume that whatever is inside of that call is just going to run and then we move on to the next instruction now let's hit f7 and if we hit f7 we see that our eip is resting on this next call which is going to call to the memory location f71792 and we can see that right here but if we hit f7 one more time whoa where did we go we actually called to the memory location of f71792 and we are now inside of that call now i'll refer to this as taking the call if there's a call instruction i'm going to take the call by pressing f7 and stepping into it and once we step into it we are now telling the debugger okay show me every instruction and run through each of these instructions that happens inside of this call function remember that there will be a call from a certain function that's going into another part of the program it does whatever that part of the program is designed to do and it returns a value out to the real world so to recap f8 will step over and that means that any time it hits this call it will jump right over it and assume that everything inside of that call has been executed and on the opposite side f7 will step into the call and then we can see whatever is happening inside of that call itself so we're probably a little lost at this point just because we were going over just the controls of a debugger so let's go ahead and go right up to the upper left here and hit this restart button and remember how i said that a debugger is kind of a one-way street you can always restart the program and go right back to where the operating system hands over control and that's different you can't exactly go back a couple of instructions so if you if you step over an instruction you want to go back tough luck you gotta go back to the start and find it again but there's another thing that we can do to make this a little bit easier so let's hit f9 from the start here we're now at our break point for the entry and so the program is very nice and sets us up with a break point right at the entry but let's actually make our own break point so let's hit f8 a couple times and let's say that we get to this call right here and we say i wonder what's happening inside of this call i'm going to set a breakpoint here so that every time i run the program i can just stop right on this call and then step into it step over it and just kind of play around with it and see what happens the way to set a breakpoint is f2 hit f2 on any given instruction that the eip is currently on and you will set a breakpoint you could also click right here on this little breakpoint enabled button and it'll put this little red dot right next to that instruction so to set a breakpoint f2 or click on the little red dot right here now what does a breakpoint do let's restart the program and we will hit f9 one time will bring us to the entry point and hitting f9 one more time will hit us to the first break point that we have set now you can set as many of these break points as you want we could set one here let's set one here let's scroll all the way down here and set one here let's set one here and after i've set these breakpoints now every time i hit f9 it will land me at that next breakpoint if it's going to be executed in the flow of the program so i can keep hitting f9 and it will just jump to the next breakpoints so breakpoints are super super useful to help you understand the control flow of the program and to be able to control exactly what instructions are executed when and so the name of the game during advanced dynamic analysis is to find the most interesting instructions that are executed because there's a lot of junk in here there's a lot of stuff that we don't care about we need to find the most interesting instructions that are executed and set break points on them and then step into those instructions and see how they are functioning and so in the next video we're going to take this program we're going to run through it until we find interesting instructions set breakpoints on them and see what we can find so meet me there all right picking right back up from where we left off so right now we're kind of in the middle of the program here and we can go ahead and return to the start by pressing the restart button so let's go ahead and do that now the other thing that we want to do if you go over to this tab right here with breakpoints we can go ahead and see all of the breakpoints that we have and we can see where in the memory on on exactly which address those breakpoints are set and so we can actually just remove these breakpoints because we're not going to need them right now we need to start at the beginning of this program and set breakpoints in the interesting locations for where we want to determine what the program is doing so go back to the cpu tab right here and that will get us back to the main cpu view all right so like i said the name of the game is to find the interesting calls inside of this program set break points on them and then step into those break points and see what else the program is doing now you can hit ctrl f2 as a handy little shortcut to restart the program so let's restart the program now if we restart the program one press of f9 gets us to the entry point if we press f9 one more time the program hangs it sees that we've got dll loaded some other stuff happens and the debugger stops so if we hit f9 two times what we are doing is executing the program completely and then the program exits and returns out of the debugger and then the debugger it basically has nothing no information to go off of so let's restart so where exactly does this program execute so what we can do is hit f9 one time go to the entry point and then start hitting f8 until we notice something happen and so eventually at a certain point this program is going to hang once we pass one of these call instructions and we're not quite sure where that's going to happen but it happened right there so eventually when we hit this call instruction it hangs for a moment and that's interesting and we're not exactly sure what's going on there but i'm going to go ahead and set a breakpoint there so let's hit f2 right on that we can highlight this one this call to drop or download from url.exe so we can right click and we can select follow in disassembler we can follow in disassembler and we can see that this is the part of the program where things start to happen now remember from the static analysis both the basic and the advanced static analysis remember that we had some api calls that were happening inside of this program this program opened up a handle to a url that was out on the internet somewhere and one of two things would happen if the handle returned true if there was a website alive at that url one thing would happen and if it returned false another thing would happen and if we see we start reading into these instructions we can see that the code starts to look pretty familiar to us so it looks like we've actually found our main method and so if we find this call to dwordpointer w remember that's the api call that we were using to open the handle to the url now remember just like in the advanced static analysis section let's count back on and see what's pushed to the stack right before this api call we have a push to one memory location that looks like if we drag this over a little bit it looks like the memory address f73288 is holding mozilla 5.0 recall that for the internet open w api call we need the user agent and the rest of the arguments that are pushed onto the stack can be zeros now actually let's go ahead and minimize that and let's go back into cutter and we can start to cross correlate tools of course we're going to use dark theme here and we will select the exact same program that we're currently debugging and we'll load that right into cutter and open it up and hit ok now let's do a side by side comparison so we're going to go ahead and find the main function so we'll type in main we'll find this main function here and then we're going to find the exact same api call that we're looking at inside of the debugger and let's actually put this on one side and this on the other side so it's nice and easy to see and so right where i've highlighted inside of the debugger we have the call to the api of internet open w and right over here in the output of cutter we see that in the assembly instructions we have the exact same thing now the memory location is actually live inside of the program because this is running now now in cutter this is static analysis of the binary is not running and so even though we have the call to the api here it's not loaded into the operating system and available to actually be run but over here in the debugger we actually have the memory location inside of the binary to execute this program which is f73288 so with these two side by side we can actually look at what's happening inside of the cutter output and what's happening inside of the debugger and it's actually exactly the same thing see where i have highlighted in the debugger right now we are making a call to the internet open w api call and one two three four five arguments are pushed to the stack right before this happens now where have we seen this before if we go over here and what i'm highlighting in qatar right now on the left side we have the call to the internet open w api and we have one two three four five arguments pushed to the stack before this happens so let's go ahead let's set a breakpoint so if we scroll over we'll select the exact precise location in memory where these arguments start getting pushed to the stack and we'll hit f2 and we'll set a point right there and so let's restart the program and we'll hit f9 and we'll hit f9 and right now we've hit the break point where we've started to step into the main part of this program let's hit f9 one more time and then let's hit f9 one more time and we are now at the location where these arguments start getting pushed to the stack right before the internet open w api call is made so let's minimize cutter so let's first make sure that inet sim is up and running and if we go over to remnux i do have inet sim up and let's go ahead and open up wireshark and now this is the idea of cross-correlating different tools with the debugger because we can control the exact flow of the program we can start to see exactly when these indicators of compromise start to spring up so let's watch as our arguments are pushed right onto the stack so pay attention to the stack down here in the bottom right corner we will hit f7 and we push a zero onto the stack we will hit f7 and we push another zero onto the stack remember that these are the arguments being passed into the parameter f7 f7 we push two more zeros onto the stack but now we're about to push one of the parameters that actually has something on the stack we hit f7 and if we will maximize this for a second we see that this argument is now on the stack the argument is pointing to the memory location and in that memory location we have the string mozilla 5.0 now if you recall the documentation for the internet open w api call the argument that we just pushed onto the stack is the argument for the user agent string so we're saying to internet open w we want to open up a handle and we want to have the user agent of that handle be mozilla 5.0 so let's bring this back over to the side so we have set up our api call of internet open w if we press f7 one more time we will jump into this api call and at this point the program will simply set up all of the things that it needs to do to set up this api call and then returns back to the main part of the program so to recap we set a breakpoint right here we watched our arguments get pushed onto the stack we watched the user agent string get pushed onto the stack and then we called the api call of internet open w when we stepped into this call it performed everything that it needed to do to perform that api call and came back out and now we can move down to this next call which is another interesting call that we have inside of this program so after we've made that api call we are now moving more data around to prepare for another call so let's move down here we take another call and then we start pushing more arguments onto the stack so starting right here we're pushing more zeros and then a few more arguments onto the stack so let's see what happens we'll hit f8 f8 and we've pushed two zeros onto the stack but we also start to push some memory locations we push two of those as arguments and remember what are we setting up to do well if we make this a little bit bigger we see that this next call that eip is currently sitting on is a call to url download to file w now we've pushed all of the arguments that we needed for this call right here and so if we hit f8 what's going to happen is this api call will be executed and we will perform the download from the url so watch carefully in wireshark because all i need to do is hit f8 and it looks like we've got http traffic tcp traffic and http traffic coming from our host to inet sim and it looks like we've got our telltale get to favicon.ico and remember that in this program download to url we are getting favicon.ico and writing it to the file system now notice where eip is currently resting we are currently on an instruction of test eax against itself test eax eax so test is going to set a flag in the memory registers if the ended result of these two registers is zero and so if we go over here we see that there are flags of the registers that are set to one or zero based on different results now if we test the contents of eax and do a logical and against itself and that result is zero this flag will set now read the contents of eax the contents of eax right now is completely zeroed out and the reason for that is because url download to file w will return true or false based on what happened in the execution of the program we made the api call we downloaded something we got our favicon.ico right here and then the api call says hey i succeeded so i'm going to go ahead and set the contents of eax to zero and then the next instruction is saying all right now test the contents of eax against itself so let's go ahead and hit f7 and now we have a zero flag which is right here a zero flag set to one the zero flag is set to one because we tested the contents of eax which was completely zeroed out and it said hey we've logically ended eax against itself and there was nothing in eax so we're going to go ahead and set the zero flag and now we go to the jne instruction so jump if not equal so jump if not equal is going to evaluate the zero flag and say if this flag is not set i am going to jump to another location and in this case that location is f71142 now we could go take a look at what that is but we're not actually taking that jump because the zero flag is currently set but something interesting i want to point out is that because we can control exactly what happens inside of the debugger we can actually click on this zero flag and we can set it by double clicking it we can set it back to zero and now we will actually end up taking this jump call if we hit f7 and we can see that by hitting f7 and we've now jumped to the location f71142 so always remember the point of this is that while you're running the debugger you have complete control over this program you can patch instructions you can set the flags so that jumps are taken or are not taken you have complete control over this binary while it's inside of the debugger but we didn't actually want to take that jump call so let's hit restart and i'll minimize this to make it easier to see and we hit f9 we hit f9 we hit f9 and we're back to where we started pushing those arguments onto the stack so let's follow through that one more time this time we'll hit f8 we push a bunch of arguments onto the stack and we call internet open w we do some more work and we call another api call we push a few more arguments onto the stack and remember watch wireshark here let's scroll all the way to the bottom remember keep your eye on wireshark this is the location where wireshark actually shows that we are making a request to our webpage we test the contents of eax which is currently zeroed out and we will not take this jump because we had a zeroed out eax so we go immediately to the next instruction and now we are pushing more arguments onto the stack to prepare for this next call which is making a call to internet open urlw let's go ahead and pass right over these next calls here because we want to get down to this one which is calling shell execute w remember that the one two three four five six parameters that are pushed onto the stack right before this call to shell execute w are the arguments that are needed for this api call and ostensibly if we hit f8 right now this shell execute api call would take place so let's actually set a breakpoint there we hit f2 and we set a breakpoint and now that we have a point on this let's actually open up procmon and again the name of the game here is using the debugger to control the flow of execution while simultaneously looking at other tools and extracting insights about exactly when certain parts of the program execute their functions so we'll do process name contains download from url and we will add that in as a criteria and we'll filter on that and so now if we hit f8 one more time we should see some activity over here from our download from url executable that's inside of the debugger so always remember that you can combine these tools because you can use the debugger to control exactly which instructions are executed and then you can look over in procmon and see oh okay so once that shell execute w api call was made i have a whole bunch of results in procmond that show me what's going on and if we scroll all the way down to the bottom here we have a call to see user's husky desktop ping 1.1.1.1 and then it pipes that to the contents of devnet and then it executes the cr433101.dat.exe which is in the public documents directory so let's open up to public documents and we will go to this pc and we go to the c drive and we open up users and we go to public and documents and remember this cr433101.dat.exe is the thing of interest so if we delete that let's go ahead and restart the program and we'll keep an eye on the contents of the public documents directory and let's see if we can determine exactly when that file is written to the file system so we hit f9 a few times we get to our breakpoints where things are pushed to the stack we hit f8 and we make our first api call internet open w we hit f8 and we make another call we push more arguments to the stack and right here should be the time that our file appears on the file system because we're making the url download to file w call so let's hit f8 and there we go it looks like cr33101.dat.exe appears on the file system when that api call is made and now let's maximize the screen just to bring it on home let's see how this program executes and finishes out let's hit f8 we make the call to internet open url w we keep hitting f8 we push our arguments to the stack and we hit that shell execute and we hit f8 one more time we xor eax against itself and then we make another call and we hit finally hit this return instruction when we return we are now on the we're basically exiting the program at this point we're wrapping up we're going to make just a couple more calls we push esi and then we make a call to jump and exit and so with that call to jump in exit if we take that call and hit f8 we will finish execution of the program so i know that was a lot of information but what i want you to take away from this is that the debugger is extremely useful for being able to control exactly what instructions inside the program should be executed you have complete control over it and then you can take things like procmon and wireshark and look at the file system and triangulate exactly when these malicious activities are taking place on the file system or the network signatures are happening to download something from a url or write something to disk or run some kind of command so that's our primer our crash course on debugging incredibly powerful so meet me in the next video and we'll start our second challenge in this course which allows us to combine all of the skills that we've built up to this point so meet me there all right analysts another day another sample let's go ahead and open up to the lab repository and go find 2-3 challenge sicko mode and this is going to be our second challenge binary now let's go over to the repo readme which is available on the get page and we'll scroll down and let's look at the scenario brief challenge two second mode analysts this specimen came from a poor decision and a link that should not have been clicked on no surprises there we need to figure out the extent of what this thing can do it looks a little advanced perform a full analysis and send us the report when done we need to go in depth on this one and determine what it is doing so break out your decompiler and debugger and get to work the ir team all right and we set up our objectives we're going to perform static and dynamic analysis on this malware sample and we're going to extract facts about the malware's behavior and we'll use these facts to answer the questions that are in the scenario below so these are the questions that we'll be looking at and we are going to employ every tool and methodology and tactic in our arsenal at this point so we will be doing all forms of basic static basic dynamic and to the extent that you're comfortable a limited amount of advanced static and advanced dynamic analysis and so go ahead and break this binary open take a look at the questions in here see how many of these you can answer and remember if you get stuck we always have the answers directory right here so you can go in and take a look at those answers so challenge two sicko mode this one's fun i had a lot of fun putting this one together so good luck remember the answers are always right here in this directory if you get stuck but good luck and meet me in the next video for the walkthrough hey everybody all right we're talking about challenge 2-3 sicko mode so we'll be covering the answers for the sicko mode binary this is the walkthrough video so if you have not done so already go ahead and try to complete the challenge and answer the challenge questions but if you have completed that or if you got stuck go ahead and continue with this video so sicko mode is a binary that is the first challenge that's introduced after all four phases of analysis are taught in this course and so the idea is that by this point you should have a pretty good methodology for the basic phases of analysis and have just kind of gotten your feet wet with the advanced phases of analysis and so i wrote this binary specifically to support the learning in that regard and the idea is that it's very helpful during the analysis of the sicko mode challenge binary to combine different phases of analysis so in other words you'll start with basic static and basic dynamic and then you'll break out cutter and the debugger and you will combine the different tools and methodologies to get the insights out of this binary now there were a few curveballs in here and i'll point them out as we go so let's jump right in we're going to go down to 2-3 challenge seko mode and we open up unknown.exe dot 7-zip with the standard password of infected and we will bring unknown.exe right to the desktop and so we will start by doing our normal round of static analysis so we'll launch into a power shell prompt and we will do all manner of things that we need to do for basic static analysis so get file hash and then algorithm we will pass it in sha 256 and then desktop unknown.exe we'll take this file hash annotate that in our notes submit this to virustotal at the time of recording this of course there are no results for this binary so i'll start following along with the challenge questions and we're going to talk through each of them one by one so question number one what language is this binary written in so from an early analysis perspective we can get this pretty quickly by using floss against the binary and of course i already know the answer to this so i'll go ahead and put in what the answer is the binary is written in nim and the way we can tell that is by flossing the binary and identifying a lot of the strings that indicate that this binary is importing nem libraries and is using three particular methods around the main method we have nim main we have nim main inner and nim main module and so binaries that are compiled in nim they have about three prelude method calls before they get to the main method and so you'll see that really the only thing you can surmise here is that unless there was a lot of effort by the malware author to change a lot of these strings to make it look like this was compiled in nim which is an unlikely scenario we see all manner of things that indicate that this is a nim binary uh name imports tables http client that kind of thing and we have all the method calls that have nim as a prefix so pretty pretty straightforward at that point uh next question we need to determine the architecture of this binary so this was interesting because if you go to what you would normally do and use something like pe view you'll load up pe view and you'll load unknown.exe into pe view and it says this version only provides a limited view of 64-bit files now it's worth mentioning one of the curveballs of this challenge is that this is a 64-bit binary and we really haven't introduced a lot in regards to 64-bit analysis so my point here is that this challenge could still be completed even if you don't know anything about 64-bit binaries all you needed to do was focus on the big moving parts and focus on combining the other phases of analysis with the advanced static analysis and advanced dynamic analysis when you break this thing open in cutter and the debugger the very fine details of this binary look a lot different instead of eax there's rax instead of eip there's rip so if you get sucked down into the weeds with this binary you might have a pretty hard time determining what's going on but all of the big overarching moving parts are the same so we'll get into that a little bit more as we go along but this was one of the indicators that this is going to be a bit of a curveball you're not working with just a 32-bit binary we're working with 64-bit which we haven't really learned a whole lot about so we need to kind of think on our feet here but that's okay so let's get out of pe view and actually go into pe studio and pe studio does have support for 64-bit binaries and we'll throw this right in here and we take a look this could also be part of our initial run of basic static analysis where we load this into pe studio so in any case the answer for that question this is an x64 architecture binary for a 64-bit cpu and we can find that out by loading it into pe studio and if we inspect it at the assembly level we'll notice that there's a whole bunch of stuff that we don't really that we've never really seen before now the next question assumes that we have continued through the static analysis phase and we've started to perform basic dynamic analysis so when we move to do basic dynamic analysis we do have our inet sim instance up and running so the next question is under what conditions can you get this binary to delete itself so this is a self-deleting binary and there are a couple of instances written into the code that will make this delete itself from disk so the first instance is that if this executable runs and it cannot make a callback to its first callback domain it will close the handle to that url and then delete itself from disk and so if we have inet sim up and running and we'll actually open up let's open up wireshark as well so we can see this happen in real time listen on the correct adapter so if we have inet sim up and running and we double click on unknown.exe if we go over to inet stem we'll actually start to see the exfiltration of the data occur which we'll cover a little bit here in a second so the the point is that if you have init sim up and running you won't be able to determine that this binary can delete itself from disk until after the x alteration routine is completed but if we ctrl c and stop inet sim and we start getting these packets that say that the binary can't communicate with its callback domain we go back over here and we see that unknown.exe is gone now it's deleted itself from disk and we can actually let's go ahead and watch that happen again unpack unknown.exe standard password of infected we bring this right out to the desktop and again initsim is not running at this point let's double click it thinks for a second and then it is gone poof deletes itself from disk so that is one of the conditions in which this binary will delete itself from disk the other two require a little bit more on the advanced analysis side and i'll just say what they are right now we actually kind of just saw one uh if the executable is interrupted in the middle of whatever it's doing so we're not quite sure what this executable is doing right now but if we interrupt it if we kill inet sem in the middle of its routine it will delete itself from disk and then the final criteria here is that if there's ever an exception hit or if the executable finishes and exits without error code it will also delete itself from disk now moving on to the next question does the binary persist if so how this is kind of you need to be able to determine when something is not doing a particular function with this question and if you search around if you look with procmon or any kind of tool that can determine host-based indicators you could take a look at the registry for this one but really when it comes down to it there are no persistence mechanisms in this binary and the idea there was to use tools like procmon and run the binary and look and filter on the criteria to identify if there are any host-based indicators happening if a file is written to disk into a registry key anything like that there are no persistence mechanisms for this binary now next up we need to determine the first callback domain for this sample so let's get our sample back out to the desktop and we'll throw remnux and flare vm to each side of the screen so we can see this a little bit more easily so when we have unknown.exe out on the desktop and we do have to start inetsim back up we'll go back over and we will clear out our output from wireshark and go ahead and start listening again so we need to determine the first callback of this binary so for basic dynamic analysis we're going to get a back here when we double click and we look through the tcp handshake that happens and then there's the first http packet that comes across and let's open up the header for the http packet and take a look we have http colon update.ec12-4-109-278-3-ubuntu 20-04.local so this is just big gross long url that's in use and it kind of looks like an aws instance not quite but it kind of looks like one we've got a user agent of mozilla 5.0 so this is our first callback information let's go over to the strings output and instead of grepping for nim let's actually grep for this url so i'm going to go ahead and copy the value and i'll throw this right into the floss output and grep for it and if we grep for this it's not going to be in the output of floss and so that was another bit of a curveball here in that the strings of the binary don't contain this first callback information so the initial callback domain was not in the strings but the exfiltration domain was so if you were not paying attention you might have jumped right over the initial callback domain and thought that the exfiltration domain was the first callback that was mentioned so if we go down to maybe one of the first exfiltrations so here is an example of the binary exfiltrating and so our uri here is http colon cdn.altimeter.local feed and then there's kind of like a parameter in the post field so you may have said oh that must be the first callback domain because that's where this exfiltration is taking place but that's not the case it's actually a different one and this binary is splitting web requests between its first callback domain and the actual exfiltration domain but we'll get to that here in a second but to answer the question the first callback domain is http colon slash update.ec12 etc etc and that was not present in the strings of the binary as we can see trying to grip for it and it comes up empty-handed under what conditions can you get the binary to exfiltrate data so we've already kind of answered this if you go back to the binary and let's actually kill inet sim and the binary should delete itself from disk here in a second because ion and sim has stopped in there it goes so let's clear the output of our wireshark and start listening again on the same interface and get inet sim up and running so the idea is that we need to determine how this binary is able to exfiltrate data and under what conditions well we already kind of know that so the answer to this question is that the binary must contact the initial domain that we just found of update.ec12-4 etc etc if it makes a successful connection to that url it will then start to exfiltrate data and the data that it's exfiltrating is cosmo.jpg now if it does not connect to that url it will close out the handle to that url and then delete itself from disk now the next question is the exfiltration domain and again remember this is different than the initial callback domain so if we do our callback one more time we get our tcp handshake opens up and then our http requests and the first one that comes across the wire that we can read is to update.ec12 etc etc ubuntu.local and so that is our callback domain but then we scroll down and like we saw earlier we have a response and then we get to the first http request that indicates that there is data being exfiltrated let's open this up to see it a little bit easier and our full uri here is http colon cdn.altimeter.local and then it is posting to a specific uri which we'll get to here in a second so again these two domains are different there is a callback domain and then an actual exfiltration domain so the next question is what type of data is exfiltrated the file is cosmo.jpg but how is the files data transmitted and so if we open up to our wireshark output we're going to the feed uri so like a feed page and there seems to be a parameter of post equals and then this has a big block of text inside of it so if we check between these different requests to this page we see that this data is different every single time one thing that you can use to form a hypothesis is that the data from cosmo.jpg is being read in by the malware in some way and encoded or maybe encrypted and then used with this get request to this exfiltration domain now it's interesting because this is a get request it's not like we're actually sending any data into the website itself like posting a form or anything like that but even by virtue of the fact that this post equals right here is going to be filled in with this big block of text that text is still going to be present on like the web logs of wherever this web server exists so even though this isn't really a post request in the true sense of the word you're still sending data to the website by making a get request to it and that data can be scraped on the back end of that website by whomever is using it to exfiltrate data so at this point we're not quite sure what's going on with this post equals in terms of is this encoded is this encrypted but we do know that this big block of text is being sent after we hit go on this binary and it's being used in a get request to this altimeter.local uri so those are facts that are worthy of note and we'll keep moving on now for the final few questions we're going to move into advanced analysis and so we will go back over to flair and we'll just take a look at some of the final questions in this challenge and we'll see if we can use some advanced methodology to solve them so the next question up is what kind of encryption algorithm is in use so the way that we can determine that there are a few ways to do this one of them is by looking at imported libraries and even the string references of the imported libraries so if we go back over to commander so by carefully reading through the floss output we can find something that has to do with rc4 and so even though that's not enough to prove that rc4 is the algorithm in use that is something that we can start to track down when we move into the advanced dynamic and advanced static analysis phases and so with the output when we grep for rc4 we do in fact have a method call to the 2rc4 method and we also see that we might have another library import right here with rc4.nim.c now again in basic static analysis and by inspecting the strings there is not enough information to go off of at this at this point so we really do need to correlate that with advanced methodology so when we go over to cutter and we load this in we can go ahead and look for the 2rc4 method inside of the binary and we'll go over to graph u to get a better view of this so if we look in here we do have the 2rc4 method call now we need to go back out to wherever this 2rc4 method call is invoked from and so after a little bit of looking around we find that the steel stuff the sim.steelstuff method inside of the cutter output is going to have a call to the 2rc4 method and so if we follow this down eventually we get to the point where we get into this loop that starts right here and then as we go down through the loop we see that the information however this binary is bringing information into the program it eventually will try to encrypt it with rc4 now with that having been said the next question is trying to locate the key that's used during the rc4 encryption routine and actually the earlier phases the dynamic analysis phase might actually help us a lot more than looking through the assembly instructions of this binary so if we open up procmon and we'll go ahead and filter we will do process name contains unknown and we'll include that and then we need to look at operation is create file so with process name contains unknown and operation is create file we'll go ahead and filter on those two criteria and so we do have output from the last time that we ran it but we're going to go ahead and just clear out that output and then we will run unknown.exe one more time and so we get a nice clean output to look through here and if we scroll down we see that one of the things that occurs during the execution of this program is some kind of create file operation to see userspublicpassword.txt so let's go track this down we will go to c users public and we have password.text right here so if we open this up we just have the text seco mode and this is the password for use in the encryption routine now the final question here is what is the significance of houdini so we've already kind of covered this in a way houdini is the method call used by the binary to delete itself from disk and if we type in houdini into cutter to search for it for the method call itself we find that this is actually written into the program as houdini but to know what the significance is of this we need to know where this is used so let's go back to the main method and notice that in a nim binary there are really kind of three main methods here that we have to deal with we have nim main we have nimm main inner and nim main module and the one of most interest to us is going to be nim main module so if we go to nim main module we can kind of just check really quickly to see where houdini is used so we see that houdini is invoked in the instance where after we check the kill switch url we will test the contents of al the lower bits of the eax or rax in this case register and then we jump if not equal to so if the zero flag is not set we're going to jump over to call houdini and then we jump to the end of the program which returns out of the main method so that's one instance where houdini is called and that correlates to what we found earlier in that if we check the kill switch url and we can go into this method call and understand a little bit more about what it's doing but from a high level if we check the kill switch url and it does not return true then we're going to call houdini and exit the program now another instance of houdini can be seen right here and so if we move down a little bit if we check the kill switch url and it returns true we do a little bit more work and we go over here and we test the contents of rax if rax does not set the zero flag then we go over and we perform what i consider to be the main routine in this binary which is unpack resources and steel stuff but on the other side of that we call houdini and then interestingly enough either one of these paths will lead back to the last instance of houdini which is right here so that correlates again with what we said earlier if the binary is interrupted at any point it will call houdini in this path of the execution flow and even if unpack resources and steal stuff complete successfully it will also call houdini and delete itself from disk there as well so that is the significance of houdini and so from a very high level we check the kill switch url and if we don't get a good result we delete ourselves from disk if we do get a good result we kick off the main part of this binaries routine which includes unpack resources and steel stuff if at any point we get interrupted we call houdini and delete ourselves from disk and then finally at the end of either of those instances we will call houdini and delete ourselves from disk and that concludes the walkthrough for the sicko mode challenge well hey everybody we've made it to the end of the five hour release of practical malware analysis and triage on youtube i thank you for coming along with me in the course and i wanted to give this to the community as a gift because of just the support and the love that i've received from the community it has been my personal and professional honor to be your instructor for this course now if you have made it through the five hours on youtube and you're hungry for more i would like to remind you that practical malware analysis and triage the full course the whole nine hours is available on tcm security academy for a purchase price of 29.99 us dollars and now if you have made it through the youtube section of the nine hours we have completed five and that would land you right about here at the end of the sicko mode walkthrough and you can see there is tons more content in this course we go into specialty class malware we talk about maldox and shellcode c-sharp we talk about mobile malware sandboxing automating analysis and we also do something very important rule writing and report writing to tell the world what we found during our analysis and so if you'd like to purchase the course there is tons more content to discover in this course so please go to the tcm security page and find practical malware analysis and triage and of course the links of those have been in the description and throughout the course i thank you again please let me know if you have any questions feedback comments concerns memes malware samples you can send them to me in my inbox i always love to hear from students and i love to help you out on your journey and wherever you go from here please remember take care of yourself take care of each other i'm happy you're here and the world needs you that's it take care [Music]

Channel: HuskyHacks

Views: 112,989

Keywords:

Id: qA0YcYMRWyI

Length: 352min 42sec (21162 seconds)

Published: Mon Aug 22 2022