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 COVID-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 cybersecurity 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 cybersecurity 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 @HuskyHacksMK, 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, prod, slice, splice, dissect, inspect 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#. 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# assemblies in which we will decompile and analyze the near source code of a C# 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 Jupyter 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. A 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 of 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. 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.

All right, 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 111-111-1111-333; 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-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 unallocated 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 of 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 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 Additions 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 Additions 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 remnux.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 REMnux has finished downloading. Now we’re going to make a new directory, and we’ll call this PMAT REMnux; 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…

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 a 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. We can go ahead and click import, and this might just take a second.

Now, after the install, we'll have our pmat_remnux virtual machine guest operating system here, and we can go ahead and click start and fire this bad boy up. 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 mkdir`. 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/cdrom`, and it will say `device is write-protected, mounting read-only`. That's totally fine. So we will go to `media/cdrom` 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 `./autorun.sh`. 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. 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 VirtualBox manager here, and we will remember we paused our Flare-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. 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 of times until the prompt comes here and `Set-ExecutionPolicy` or `ExecutionPolicy`, 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 `-UseBasic` and hit tab-autocomplete for `UseBasicParsing`, 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 `C:\users\your username`—for me, this is `husky\desktop`—and we do a `dir` command, we'll see that my `install.ps1` is right here. So all we now need to do is `.\install`, and we're going to let this run, and this is going to 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 Flare-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. Mine, 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 of 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 of 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 Flare-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 Flare-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 base 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.txt` 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 "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 going to 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.txt` 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 going to get rolling on setting up the network, and then we're going to 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_remnux—here are two virtual machines—we're going to 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 VirtualBox 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 Host-Only Ethernet Adapter Number Two. We will click this DHCP Server Enable, and we notice that we have a 192.168.x.x 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.255.0; that makes it a /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 of 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 /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 of 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 Flare with our password of `password`, and Remnux 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 `ip a` 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 Remnux, and over here, 10.0.0.4, we're good on Flare-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 request could not find host google.com. Please check the name and try again.` Excellent; that's what we want. Over here on Remnux, 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.4`. We are four over here on Flare, and it's looking good. And over here, we do a `ping 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 Remnux. Flare-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 Remnux ends up doing is it ends up being a couple of 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 `inetsim`, 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 Remnux, 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 Remnux is sitting on this network to be able to respond to requests like that. There are, in fact, programs that do this on Flare-VM, but we're going to do them on Remnux 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 tcpdump. 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.

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 the 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 Remnux. 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 tcpdump, 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 inetsim, I-N-E-T-S-I-M. And if you run inetsim, 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.

So before we run inetsim again, we're going to `sudo nano /etc/inetsim/inetsim.conf`, 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 Remnux that you're more comfortable in, just go ahead and use that one; no big deal. Anyway, we are up at the top of the inetsim 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; 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. 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.

All right, 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 127.0.0.1, but that's not really going to help us; we want this to be the IP address of our Remnux 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 `ip a`; 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 inetsim again; we'll do `inetsim`, 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 inetsim 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 Flair VM, and the reason I wanted to come over here was to show you how inetsim 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 inetsim 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 OK, and it serves us some HTML. So what if we go to `https://` 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 inetsim 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? Inetsim—this is the inetsim 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_stage_payload.exe`; instead of just returning a 404 and saying, "Oh, I don't know what that is," inetsim 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 inetsim 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 `aseaseasd.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 inetsim, 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.com`, and we get inetsim. We can put in `fancyladsnacks.info`, and we get inetsim. 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 inetsim 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 Flair 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/huskyhacks/pmat-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/huskyhacks/pmat-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.

All right, 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-detonation." So once we have our name put in as "pre-detonation," 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 7-Zip 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/bossfight_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 `wannacry` subdirectory, and I have `wannacry.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 lowercase: 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 `.exe` to the end. When you add a `.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: `wanna decrypter.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 pre-detonation 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 Flare 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 InetSim, 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 Sysinternals Suite, which is provided by Microsoft. Now you can download this individually, but you can also go download the full Sysinternals Suite. All right. Now, once we've downloaded the Sysinternals 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 Sysinternals Suite/, and that should extract all of the tools in the Sysinternals 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 .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 of 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 .exe, 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 .mals 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, .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 Zero 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 of different things here. We have this 7-Zip 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 the 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 .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 .mals 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 sink, 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 disarmed 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 joined 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 filled 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 macOS. 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 Zeltser 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.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 clear web, 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—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.mals directory. 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 malware.unknown.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 Flare; it should get you to the executable. And then following that, we will give the name of the sample, which is malware.unknown.exe.mals, 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 VirusTotal 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://google.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:// and then this could be any malicious domain.com/, and this could be evil.exe, 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://domain.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 four 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 InternetOpenUrl, wInternetOpenUrl, 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://ssl and then maybe like a a domain name here, helpdeskbros.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 binary's 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 sitting 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 Utilities 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 PEview, so double-click and open up PEview. 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.mals. 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 PEview, 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 PEview 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/2021, and you can see up here that this was compiled on 9/4/2021. 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 .text section. So the .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 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 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 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, 15A1. So let's go ahead and go back to our programming calculator, and 15A1, and it looks like that is 5,537. 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 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 PEview, and if we go to the section of the .rdata and look at the Import Address Table, this might be one of the most important parts that we can see inside of PEview. Now to really understand why the Import Address Table, or IAT, is so important, we need to look at something called the Win32, 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++ can make use of these functions instead of tapping into the very, very low code of the operating system?" And so what you can think of these functions as 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 a URL, you can use this API," and in your C or C++ 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 output 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 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 ShellExecuteW, 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 Google's, and we're going to say, "The Windows API ShellExecute." Now, Microsoft has documentation for each of these functions. So ShellExecuteA 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: URLDownloadToFile. 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 going to do URLDownloadToFile. 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; 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 PEview 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 Twitter right there—they released this, which is malapi.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 malapi.io. And so what I liken this to is if you took something like GTFOBins and something like the MITRE ATT&CK 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 MrDocs put together 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 CreateRemoteThread. 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 kernel32. And so Associated Attacks is again a little bit like the MITRE ATT&CK 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 CreateRemoteThread. 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 MrDocs 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 MrDocs 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 MITRE ATT&CK 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 CreateProcessA 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 MrDocs some love; please follow them; they're putting out fantastic research, and check out malapi.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 mals.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 UPX, 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 runtime. 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 mals.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_packedandnotpacked.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_notpacked right here, and we're going to go back to our program PEview. So remember, go to the Flare directory on the desktop, and go to Utilities, and we're going to scroll down and open up PEview, 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 keep-alive 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 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 PEview again, and this time we're going to look at the packed sample. So we're going to select, instead of the notpacked.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, UPX1; 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: GetProcAddress and LoadLibraryA 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 GetProcAddress and LoadLibraryA 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, GetProcAddress and LoadLibraryA 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 DownloadFileFromURL 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 GetProcAddress and LoadLibraryA need to be invoked at runtime to be able to find 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 .mals 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: malware.unknown.exe.mals. 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 cybersecurity, 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 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 favorites 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 window to analyze it, or you can go to "Open File" here. 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—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 in 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 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: Kernel32, you're going to see a lot all over the place; Shell32, 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 as 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 URLMon 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 URLMon and WinInet are noted as potentially malicious because URLMon is the embedded library for OLE32 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 WinInet.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, "URLDownloadToFile" and "InternetOpenUrl"—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 sum 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 PEview, we saw that there were a few import address table calls to some API functions of note. We found ShellExec, InternetOpenUrl, and DownloadFromUrl. 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, i.e., 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 InetSim capability, and remember that we have it set to be our network's DNS server as well. So go ahead and on REMnux, make sure that you're running InetSim, 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 InetSim 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 "http://free-t-shirts.info," we'll be able to see that request to free-t-shirts.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 .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 datamanager.helpdesk.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.request," and you can kind of see it right there in the—in the autofill—"http.full_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 Greenshot 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've 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 Procmon. You can go ahead and just search Procmon and click on that icon. And this is part of the Sysinternals 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; it's 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 Procmon, 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 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 inetsim executable. So remember if we go to like doesn'texist.com/evil.exe, remember that inetsim is going to serve us up a binary that just says "This is the inetsim 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 inetsim, 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-based indicator out of this piece of malware.

Now, remember at the beginning I showed you that if inetsim 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 inetsim 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 inetsim 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 inetsim, 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.ico; run favicon.ico. 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 helpdeskpros.local/favicon.ico—if that exists, which we simulated via using inetsim 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.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 inetsim, 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 inetsim 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 msdcorelib 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 AppData\Roaming\Microsoft\Windows\Start Menu\Programs\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 msdcorelib.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 inetsim 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 AppData 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 AppData\Roaming, etc., etc., 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 C:\Users\Husky\AppData\Roaming\Microsoft\Windows, etc., etc., etc. It goes all the way down to Startup, and that mirrors pretty accurately the string that we pulled out of the binary: AppData\Roaming\Microsoft\Windows, etc., all the way down to Startup. Now it looks like it can cats right at the AppData 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 AppData 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 write 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 mscoredll.exe. If we double-click on this—remember that this is the inetsim 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. All right, so we are back out; we have rearmed our binary and reverted back to a clean snapshot.

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-based 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 TCPView. Now, I have installed the Sysinternals 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 Sysinternals Suite correctly, so I installed it myself. And if you do not have the Sysinternals 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 TCPView can do. So when we open up TCPView, 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 listening 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 -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 5555, 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 base64 -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?

All right, 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 base64 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—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 TCPView 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 Process Monitor 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 TCPView 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 TCPView, we can use Process Monitor 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 Process Monitor 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 whoami, 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 whoami.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 whoami.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 Remnux 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 whoami 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 README 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, host 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.unknown.exe.mals, 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 floss 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 InternetOpenW, InternetOpenUrlW, we have MessageBoxW, 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 Nim 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 .mals 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. All right, 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 det, and we've got 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. All right, 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 inetsim 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://serv1.ec2.102.95.13.2.ubuntu.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 msdcorelib.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 2. Basic Dynamic Analysis section, and this one is rat unknown2 unknown2.exe.mals. The last one that we did was unknown; this one will be unknown2.exe.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 .NET 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 /c flag, which means that it is able to run a command, and we've got a .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. VirtualProtect might be on might be flagged as kind of suspicious here, but VirtualProtect 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 binary's 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.info or something like that, or in this case aaa.kaduceus.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.mals, 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 greenshot 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 ... I think there are about 20 of those.kaduceus.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.kaduceus.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 /etc/hosts file on this system. So we'll do nano, which is built into flair VM by default, and we'll do C:\Windows\System32\drivers\etc\hosts, and you can of course tab auto-complete, and we'll launch into nano for the /etc/hosts file. Now this is exactly the same as the /etc/hosts 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 localhost 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.kaduceus.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.kaduceus.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 localhost 127.0.0.1. 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 System32\drivers\etc\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, 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. All right, 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 of 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 -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 Procmon 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 whoami 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/husky.

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. All right, 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.unknown2.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 of 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 Procmon. Procmon is actually a child process of this explorer.exe. So in Procmon, anything that Procmon 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 924, 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 whoami 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 Procmon 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 system32 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 bossanova tune, 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 IT 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 sum 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 Get-FileHash cmdlet, 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 SHA-256 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 command 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 -n, and I did not cover this in the course, but the -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 PEview 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 DeleteFileA or RegKeyCreate, RegKeyDelete, 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. 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.

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. 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. 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 PID 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, 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 bonus2, and let me open this up so we can see it easier: bonus2.corporate.bonusapplication.local. Now this does not resolve at this point because we don't have InetSim 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 InetSim; we can get rid of that momentarily, and we can fire up InetSim, 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 InetSim 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 bonus2.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 8443. So we can imagine this may be our callback port. And to check that, we can take a look at something like TCPView. And so we will open up TCPView. 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 command 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 bonus2.corporate.bonusapplication.local is pointing at the localhost, and we'll save and we'll exit out of the host file. And for good measure, I'm going to do an ipconfig /flushdns 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 npcap 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 whoami 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 Kali. 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 were 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 cybersecurity 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++, 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++ 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 edx, eax. And we'll talk about what that means here in a bit. test eax, eax. And then maybe something like jne, 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.downloadfromurl 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 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 SHA1 and SHA256 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/decompiler 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: C:\Users\Public\Documents\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:\Users\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.datamanager.helpdesk.bros.local/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 URLDownloadToFile. 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 DownloadFromUrl 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 decompiler 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 URLDownloadToFile, w is the actual direct API call that we're making to this ssl.datamanager.helpdesk.bros.local/favicon.ico. So that is the exact parameter that's passed to the URLDownloadToFile 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 mov, jmp, and then sub; 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 edx, eax, 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 jnz 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 checkURL, and so we will call the checkURL function. So we will call checkURL from the main method, and the checkURL 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 pickUpEggs function. And so she has told me, "Hey, pick up a dozen eggs," and so I will pass in the 12 argument into pickUpEggs. Now that's important because that argument needs to go somewhere. So when the pickUpEggs 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 pickUpEggs routine, and I'm going to call another routine: saveCatFromTree. 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 pickUpEggs function is once I'm done with the saveCatFromTree function. And the way I do that is I save the location of pickUpEggs in the EBP (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 EAX, which is the accumulator register; the EDX, which is the data register; the EBX, which is the base register; and then the ESP, the extended stack pointer; the EBP, the extended base pointer; and then the EIP, 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 argc`, `char* 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 passed two arguments implicitly: the `arg` for count (`argc`) and the `arg` for vector (`argv`). 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 `argc` 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 `argv` 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 `dword` of `InternetOpenW`. And this is an API call. Now recall from the basic static portion when we looked at this binary that this `InternetOpenW` 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 `InternetOpenA`, the API call, and let's see how many arguments are passed in: one, two, three, four, five. Interesting. So we have a perfect matchup 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 `lpszAgent`, or the user agent pointer to the null-terminated string that specifies the name of the application or entity calling the WinInet 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 `0`, `0`, `0`, `0`, 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 C:\Users\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: `UrlDownloadToFileW`. 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 (`jne`). 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 downloadfromurl.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 a callback 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/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.downloadfromurl, 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 wherefault.exe—that's W-E-R-F-L-T.exe. Now the second indicator that we pick up—and we'll have to look at TCPView real fast to see this one—is that wherefault—W-E-R-F-A-U-L-T—actually spawns an open connection for a brief moment on remote port 8443 on the localhost. So it's opening up a connection, or at least attempting to open up a connection on the localhost on port 8443, and that was W-E-R-F-A-U-L-T, so wherefault—W-E-R-F-A-U-L-T.exe. So if we run this one more time, we might be able to see that, and there is the connection right there from wherefault.exe on the localhost. So that begs the question: What is wherefault, this one right here, and then what is this one right here, which looks to be like a misspelling of wherefault? 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, wherefault 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, wherefault will collect information about that and can be used for further debugging purposes. But this right here is not wherefault.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. Lots of interesting information because we have a network signature; something's trying to connect to the localhost on port 8443, and then we have a host-based 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 wherefaults.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_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 `dword` `OpenProcess`. 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 `OpenProcess`

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 dword 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 dword arg ch into eax; 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 arg ch 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 VirtualAllocEx 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 WriteProcessMemory, 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 CreateRemoteThread. And so if we go down to CreateRemoteThread, 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 CreateRemoteThread, 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 WriteProcessMemory 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 VirtualAllocEx and WriteProcessMemory 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 WriteProcessMemory 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 CreateRemoteThread 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 localhost on port 8443. So we can open up a command prompt, and we'll get a netcat listener up and running with nvlp 8443. 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 CreateRemoteThread 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 CreateRemoteThread 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 x32dbg and x64dbg. So let's go ahead and open up to x32dbg 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 .mlz extension, if you load this into a debugger, the debugger will know how to work with it.

All right, 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 breakpoint, and we'll talk a little bit about what breakpoints 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 3 breakpoint entry breakpoint 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 eip 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. Let's go ahead and go right up to the upper left here and hit this restart button.

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 breakpoint for the entry, and so the program is very nice and sets us up with a breakpoint right at the entry. But let's actually make our own breakpoint. So let's hit F8 a couple of 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; it will bring us to the entry point. Hitting F9 one more time will hit us to the first breakpoint that we have set. Now you can set as many of these breakpoints 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 breakpoints 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 breakpoints on them, and then step into those breakpoints 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 `InternetOpenW` 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 `InternetOpenW`, 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; it's 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 `InternetOpenW` 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 Cutter right now on the left side, we have the call to the `InternetOpenW` 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 breakpoint 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 `InternetOpenW` API call is made. So let's minimize Cutter.

So let's first make sure that InetSim is up and running, and if we go over to Remnux, I do have InetSim 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 `InternetOpenW` API call, the argument that we just pushed onto the stack is the argument for the user agent string. So we're saying to `InternetOpenW`, "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 `InternetOpenW`. 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 `InternetOpenW`. 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 `URLDownloadToFileW`. 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 InetSim, 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 `URLDownloadToFileW` 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 `InternetOpenW`; 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 `InternetOpenUrlW`. Let's go ahead and pass right over these next calls here because we want to get down to this one, which is calling `ShellExecuteW`. Remember that the one, two, three, four, five, six parameters that are pushed onto the stack right before this call to `ShellExecuteW` are the arguments that are needed for this API call, and ostensibly, if we hit F8 right now, this `ShellExecute` 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 Process Monitor, 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 Process Monitor and see, "Oh, okay, so once that `ShellExecuteW` API call was made, I have a whole bunch of results in Process Monitor that show me what's going on." And if we scroll all the way down to the bottom here, we have a call to `c:\users\husky\desktop\ping 1.1.1.1`, and then it pipes that to the contents of `devnull`, 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, `InternetOpenW`; 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 `URLDownloadToFileW` 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 `InternetOpenUrlW`; we keep hitting F8; we push our arguments to the stack; and we hit that `ShellExecute`, 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 and exit, if we take that call and hit F8, we will finish execution of the program.

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 Process Monitor 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, sicko 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.7z 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 PowerShell 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 SHA256 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 Nim libraries and is using three particular methods around the main method. We have nimMain, we have nimMainInner, and nimMainModule. 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 PEview, you'll load up PEview, and you'll load unknown.exe into PEview, 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 PEview and actually go into PEstudio, and PEstudio 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 PEstudio. 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 PEstudio. 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 InetSim 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 InetSim 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 InetSim up and running and we double click on unknown.exe, if we go over to InetSim, 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 InetSim up and running, you won't be able to determine that this binary can delete itself from disk until after the exfiltration routine is completed. But if we Ctrl+C and stop InetSim 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 InetSim 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 InetSim 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:update.ec12-4-109-278-3-ubuntu20-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: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://update.ec12 etc etc, and that was not present in the strings of the binary as we can see, trying to grep 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 InetSim, and the binary should delete itself from disk here in a second because InetSim has stopped, and there it goes. So let's clear the output of our Wireshark and start listening again on the same interface and get InetSim 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: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 file's 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=, 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= 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= 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 Flare, 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 view 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 _steelStuff_, 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 C:\Users\Public\password.txt. So let's go track this down. We will go to C:\Users\Public, and we have password.txt right here. So if we open this up, we just have the text sicko mode, and this is the password for use in the encryption routine.

Now the final question here is: What is the significance of houdini? 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 nimMain, we have nimMainInner, and nimMainModule. And the one of most interest to us is going to be nimMainModule. So if we go to nimMainModule, 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 all 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 steal 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 binary's routine, which includes unpack resources and steal 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#, 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]