Transcript for:
SOC Fundamentals and Tools

Hey everyone and welcome to the security operations 101 course presented by TCM security academy. If you want to become a sock analyst or a security analyst or if you're already an analyst and want to fill in some knowledge or methodology and practical skill gaps, well, you've come to the right place. And before we dive in, let's cover some standard housekeeping tasks and set the stage for what we're going to be learning. And the first thing I'll mention is that we're actually limited to 12-hour uploads on YouTube and SOCK 101 is a long course. Uh it's about 35 hours at the time of recording and we're always adding new lessons and challenges and just making changes over time, right? Um and so doing some mental math here, we'll be able to carve through about a third of the way through the course during our time together here, but just know that it's sort of far from the full SOC 111 curriculum. And if we take a look at the core syllabus, uh, you know, we'll be able to cover up to sort of our lab setup and, uh, the security operations fundamentals and understanding where our role fits in in the sort of grander scheme of things. Uh, we're going to deep dive into fishing analysis, right? And talking about all the different tools and methodologies that we have available to us to identify suspicious or fishing emails. And then we're really going to get into network security as well, right? And learning how we can both collect and analyze and sort of make meaningful connections and correlations from network traffic. And we're probably going to cap it off around the endpoint security module here and sort of just getting into talking about how we can hunt malware at the endpoint level. Uh but just know there is so much more to this course that unfortunately we cannot really fit in in 12 hours. Uh of course we're going to be talking about the SIM or the security information and event management system all the way into threat intelligence and even digital forensics and incident response. So a very jam-packed curriculum here. And so if you find that you've enjoyed this sort of mini version here, feel free to join us over at TCM Academy for the full course. I just want to take a moment to talk about our sponsor for this video, Flare Academy. Cyber threats are evolving fast. And staying ahead is not just an advantage, it's a necessity. And that's where Flare Academy comes in. Flare Academy is an educational hub designed to democratize cyber security knowledge. Backed by the Flair research team and leading threat intelligence experts, they provide accessible training, collaborative discussions, and cutting edge resources. With the support of Flair's industry-leading research team, members gain access to hands-on insights and training while connecting with peers and experts to tackle the toughest and newest challenges together. This is through practical sessions designed to solve real world cyber security challenges. The opportunity to engage with industry leaders, researchers, and fellow professionals to grow your skills, community meetups to share insights and experiences in both virtual and in-person events, and exclusive research and tools such as access to cutting edge reports, tooling, and intelligence from Flair's experts tailored specifically for the community. With Flare, you can learn and grow through in-depth training sessions on credential management, reconnaissance techniques, OSENT, and much more. Delivered by industry leaders like Jason Hadex, and backed by Flair's research team. You'll get exclusive access to expertly crafted solutions, playbooks, and session materials designed to address real world cyber security challenges. You'll be able to participate in expert-led discussions and Q&A channels and stay ahead of emerging threats with exclusive reports, feeds, and insights from Flair's comprehensive cyber crime intelligence. And verified members gain access to premium resources and private insights while contributing to a community that thrives on shared knowledge. And so, if you're ready to level up, join Flare Academy today through the link in the description. And so, first, I want to quickly introduce myself. And so, my name is Andrew Prince. I'm a security nerd, a a sort of blue teamer by day, and I've worked in sock environments for a number of years. Uh, and I've even dabbled into a bit of offensive security as well. I work as an instructor for TCM where I've trained thousands of analysts across many large organizations and industries, uh, including managed security providers, healthcare, manufacturing, uh, even academia and department of defense and much more. Uh, and to sort of balance out the practitioner side, I also work in DFIR consulting and security research. I have some of my background listed here, right? some education, previous roles, uh some credentials and affiliations, and some shiny collectible badges over in the lower right along with some links where you can reach myself and TCM security. And so, just to preface, I truly believe that anyone is capable of breaking into this field. And most of the industry professionals that I work with and or look up to the most did not come from a securityoriented background, right? And I can attest to that for myself as well. I used to work in graphic and web design before carving my way into the industry and uh taking more of a traditional path of help desk to system administration to networking and then finally security operations and engineering. So it took me a bit to find sort of my calling there. But if working on the sort of blue team and sockoriented work is something that you want to do or a path that you want to start going down as you gain experience. Well, I want to help you as much as I can, right? Um and that's really why I created this course to share my knowledge and experience and basically just my lessons learned, right? all of the things that I wish I knew as I was becoming a security professional. You know, uh these are all the things that I wish someone had sat me down and showed me during my first sock analyst job. And so I'm lucky to have this course as a platform or an outlet to share my stories and struggles from the field uh or different insights and present all of this along with endless hours of research and compilation putting all of this together into an engaging and practical format for you to learn from. And so all of that to say, I really hope you enjoy the course and find value from the passion that was put into it. Before we cover the course objectives, well, let's first talk about why would you want to take this course in the first place. You're here, right? So, you're obviously interested in the topic, but specifically, there are a number of important tangible takeaways that I want you to get out of this course. The first one here is well, something that we truly stand for at TCM, which is practicality. And so, this course, save for the foundation section, is going to have a practical focus. First, I'm going to dive into real tools and realistic scenarios and walk you through hands-on labs that you can follow along with and complete yourself and treat as projects and discussion points during job interviews. Additionally, there is absolutely a shortage of skilled sock analysts and blue teamers in the industry, especially right now. Organizations are looking for talent with hands-on experience and practical skills. And it's true that many skills and tools can and will be taught on the job, but having exposure to the domains covered in this course is going to give you such a strong leg up and an ability to speak intelligently with hiring managers and future colleagues, which ties into job readiness, right? And so having tangible skills and experience within these domains is going to build up such a strong holistic view of blue team operations and fill any knowledge gaps that you had previously and honestly just set you on the right path. And even if you're already in the industry, even as a sock analyst, well, I trust that we'll be able to fill in some gaps here and level up your blue team skill set, right? There might be tools or methodologies that you don't typically see or interact with in your day-to-day operations. And so, once again, giving you that holistic view and making you as strong of an analyst as you can be. All right, and here we go. These are the course objectives and all of the topics and methodologies that I want to cover throughout this course. And so first of all, we want to understand the foundational principles and practices of a security operation center, right? And this is really important. You know, we need to know what makes up a sock or even what does a sock analyst actually do? What different tools or metrics do they use and follow? We want to learn techniques for analyzing and identifying fishing attacks, right? So, how can we safely and accurately analyze potential malicious emails? and also how can we proactively protect our organizations from fishing as well. We want to develop skills in monitoring network traffic for security threats and anomalies, right? So, how can we analyze network traffic and gather artifacts or how can we create detection and prevention rules to block malicious traffic? We're going to learn how to monitor and analyze endpoint security events as well, right? So, how can we identify suspicious happenings in processes on a system? Or how can we work with our endpoint detection tools to triage alerts? We're going to learn how to use a SIM for security event correlation and analysis and incident management, right? And so, this is a big one here, but we're not just going to stick to the SIM. So, we're going to learn how can we analyze logs manually and also with tools. And so, how can we search through our SIM to investigate and correlate and identify security incidents? And next, we're going to take all of this and sort of converge to learn how to leverage threat intelligence to enhance our security operations and incident response, right? And so, what indicators or models or frameworks can we use to understand attacks better? And how can we write and consume detection rules to enhance our detection capabilities? We're going to develop an understanding of digital forensic processes and common tools and methodologies when it comes to forensics, right? So, how can we acquire and analyze forensic data and artifacts and make conclusions? And lastly here, we're going to understand the process and procedures and best practices for incident response. And so technically everything we're doing up to this point involves incident response in some way, right? We're going to talk about the core concepts of a sock analyst to monitor, detect, analyze, and respond. And the response effort, well, is always going to trickle up to any domain that we cover here. And so we're going to learn how organizations respond to incidents. And what role do us as analysts play in incident response or IR as well? And you can see how the objectives that we just covered here start to map nicely with the domains and the outline of this course. And I've kind of structured everything in a way that builds off of each other and flows nicely. And if you've taken a TCM course before, well, you'll notice that we're following a very similar structure and format here. And so the bulk of this course is going to be delivered through these byite-size video lessons. And there's going to be a major practical focus here as well. And so you'll be able to follow along and set up your own lab machines to configure security tools and install appliances or applications and perform a lot of hands-on analysis. And the course will also be full of resources and links and bookmarks for you to get your hands on additional practice or paths or research options to investigate anything we cover here in more detail. And within the public repository for this course, there will be a bookmarks file that's full of this kind of thing for you to add to your own browser for reference. And so with all of this, I'm super excited to jump in and I really look forward to going through all of this with you. Okay. And so before we get into the lab setup, I want to quickly talk about prerequisites and the available course resources. And so on the prerequisite side, there aren't too many to be honest. This is a beginner aimed course, but I do have to mention that in my opinion, cyber security itself isn't truly an entry-level field. Or to put that another way, not always a truly beginner-friendly field. And what I mean by that is there's some knowledge that is often assumed when it comes to basic IT concepts or networking fundamentals. And while it's not impossible to get by without having this, well, having this foundational understanding of these topics will certainly make the learning process smoother and less confusing during certain sections. And so in terms of some of the areas or concepts that would be beneficial for you to be familiar with well we have things like networking fundamentals like I mentioned right and so understanding the TCP IP or the OSI model you know you don't have to be an expert here and know it at a PhD level and I will say I do break down the protocols here during the network section but knowing how different systems interact with each other over the network and being able to understand things like what a subnet is an internal versus external IP address network address translation and how routers are used in the network to well route traffic through different networks. And again, I do cover this actually during the network security module. And I cover the main protocols that you're going to want to know as well. But you know, knowing common protocols like SSH or FTP or the differences between HTTP and HTTPS, you know, that kind of stuff. And then on the endpoint side, well, it would be beneficial to know how to navigate Windows and Linux a little bit, you know, and so you don't have to be an expert in the terminal or in the command line or PowerShell, but even just knowing what they are, you know, basic commands like cd and ls or cat, that kind of thing, because we're going to be jumping into the command line and the terminal a lot throughout the course. And there's no real way to throw in an operating systems 101 section in the course. It's already pretty bloated as it is, but again, I'm always doing my best to explain what commands I'm running or what arguments or parameters I'm using and why I'm using them. And so, lastly, on the infosc side specifically, there's going to be some assumed knowledge on, you know, the foundational security concepts like the CIA triad or different security controls and concepts like encryption or hashing. Again, just knowing about these things and why they're used is, you know, more than good enough for me. And while I know I do speak a bit fast sometimes, I do try to cover everything as verbose as possible, sometimes to my own detriment, but just know that I do this to make sure that you're able to follow along, right? And so I try not to just copy and paste commands and run them unless they're super redundant or not super important. And I try to write out exactly what I'm running and break down commands by their arguments to give you more of that contextual knowledge. And so now we should also talk about the system requirements. And so to get the most out of this course, I want you to be able to follow along with the labs as much as possible. And to do that, well, there will be times where we need to run two virtual machines simultaneously. And we'll talk more about that in the lab install section. And so we're going to need to install a Windows and a Linux VM. And I'll admit, I'm really not a hardware guy. I don't really do hardware. I more so do software. But after basing it on my own lab setup and looking at requirements for similar demands, you're ideally going to want to be running something like a 64-bit Intel i5 or an i7, you know, like a modern host machine with at least 8 GB of RAM and a multi-core processor is recommended to efficiently run multiple VMs. And worst case scenario, you know, if you just don't have the system resources to run two VMs simultaneously, or if it's just running too slow for you, you know, feel free to just sit back during some sections and just follow along on a single VM. You know, you can always up the resources for a single VM if you're just using one at a time, but there are always going to be workarounds. On the disk space and storage side, well, you're going to want to have around 80 to 100 GB of free storage space on the hard drive to host the different VMs and install tools and work with the course files. And SSDs or solidstate drives are recommended. You're going to get a lot better performance out of them, but we won't likely get anywhere near filling up the drives. It's more so just a theoretical limit. And we'll be setting up dynamic hard discs as well, and so it's only going to fill up as much as we use them. And again, these are just the recommended specs. And lastly, I just want to point you to the public course repository which I'll have linked down below. And I'm going to cover this in more detail along with its contents during the lab setup. But I just wanted to mention that this repository also contains some resources that might be useful to you as you go throughout the course and also takeaways for you after you finish the course. And so if you go under resources here and go under bookmarks for example, well, you'll see this sock_bookmarks.html HTML file. And this is a bookmarks file that you can download by clicking on it and then clicking on the download icon here. And once it's been downloaded, you can then import it into the web browser of your choice. And so I'll link some documentation below on how to actually import a bookmarks file for a number of different browsers. And when you do that, you're going to have access to a number of different curated resources and links. and a lot of which we cover in the course and some just for your additional reference or learning. And it's all just meant to be a nice takeaway for you to reference in the field or just for you to have as you continue on your journey. And so I just wanted to shout out the course repository here. And it might be a good idea to occasionally check up on this in case additional resources are added in the future. Now obviously because we want to be doing a lot of hands-on and practical work during this course, well, we're going to need to set up a lab environment. And we're going to do this using the concept of virtual machines. And if you've never worked with a virtual machine or a VM before or set up any kind of lab environment like this, well, don't worry cuz we're going to walk through it together. But basically, we can think of virtual machines as a separate computer or a system that's running on top or inside of our host system. And the reason why we want to use virtual machines is so that we can deploy things like a separate isolated Windows instance to install our security tools on and generate artifacts and data all without having to configure anything or mess with anything on our host like our normal operating system that we use for day-to-day work. And the other thing is we're going to be creating some different lab scenarios where we're looking at artifacts that we generate from one system onto another in real time. And so we're going to need to simulate aworked environment to do that. And at most we're going to have two separate machines or systems running. And so with that, we're going to need both a Windows virtual machine to run all of our Windows commands on and install tools and, you know, learn to investigate Windows hosts, but also we're going to need a Unix based or a Linux- based operating system. Because of course, when we think about being a sock analyst, well, we're not just going to be investigating and working with Windows endpoints. Right. Many servers run Linux and so it's just as important for us to get a good handle on both operating systems. And so we're going to install a Windows 10 machine as well as an Ubuntu machine. And to run our virtual machines, well, we need to install what is known as a hypervisor. And the hypervisor is the thing that actually creates and manages our virtual machines and allows multiple operating systems to, you know, share a single set of hardware. and it provides that layer of abstraction between the physical hardware of our machine and our VMs. And so the hypervisor I'm going to be using and the one I recommend for the course is Oracle's Virtual Box. And that's because it's free, it's ready to go, and it's highly featured. And so we can use it to create snapshots. And the installation is also really simple. And so what we're going to want to do on our host machine is just open up our internet browser. And I'm just going to do a search for Virtual Box download. And we should come across this download page here. In reality, we can just go to virtualbox.org and then just click on download Virtual Box. And so I will include this actual link down below as well as some guides if you're trying to install Virtual Box on Mac or Linux because you can see there's different host packages here for whatever operating system you're running. And so in my case, I'm obviously on Windows. And so I'm going to click on the Windows host option. And that's going to start downloading here. And once we have it downloaded, well, we can locate the installer file. And it should be in our downloads folder. And so I'm just going to open up Explorer here, go under downloads, and we can see the installer file. And so I'm just going to double click on it to run. Hit yes to this UAC prompt here. And if you're running into this error message here, well, we can see that we need to have Microsoft Visual C++ 2019 installed. And so we can just search for this package. And so I'm going to click on this Microsoft link here. And again, I'll have this link down below. And here we can find the latest version that we need to download. And so I'm just going to click on x64 here. And then in my downloads folder, I'm just going to run this installer file. All right. So, that's been installed and we should be good to go now. And so, I'm just going to double click on the Virtual Box installer now. And we're ready to start installing. And so, I'm pretty much just going to roll with all the default settings here. So, I'm just going to hit next. We're going to get a warning about our network interface here. It's just going to temporarily reset and disconnect our connection. Just keep all the defaults selected here and then click on install. All right, looks like that's finished. And so I'm just going to click on finish here to start up Virtual Box. And there we go. So if you're seeing this window here, well, you're good to go. This is the Oracle VM Virtual Box Manager and we've successfully installed it on our host. And now we can use it to build out our virtual machines that we use throughout the course. And so let's go ahead and do just that in the next lesson. All right. So now that we have our hypervisor installed, let's go ahead and install our first operating system that we need for the course, and that's going to be a Windows operating system. And so what we need to do here, I'm just going to exit out of Virtual Box for now. Then head back to Edge or whatever better browser you're using. And what we need to do is find the Windows evaluation copy. And so we can do a quick Google search here for the Windows evaluation center. And I can click on this Windows 10 Enterprise link here. And what we could do is find the Windows 10 Enterprise image, right? We can download the ISO here. And we could give Microsoft all of our information and register. And then we'll get a link to the ISO file which we could use to install the VM into our hypervisor. However, I've included a link below that will take you right to the download page. And so we can essentially skip this form. And so just navigate to that URL. And you'll see here we can select the version that we want to download or the language. And so I'm just going to go under English here and make sure to click on 64-bit edition. And in doing that, that's going to kick off the download for our ISO file. And just to note here that we're downloading a, you know, an operating system. And so essentially, this is going to be a pretty big file and it's around 5 GB. And so depending on the speed of your connection, this could take a little bit to run. And so I'm just going to fast forward here to when my download's finished. All right. And there we go. The Windows 10 ISO file just about finished. Yeah, there we go. And so I now have Virtual Box installed and my Windows ISO file has been downloaded. And so let's get a bit of organization going here. And feel free to do this however you like, but I'm just going to head to my documents folder here. And I'm going to create a folder called virtual machines. And within my virtual machines folder, I'm just going to create another subfolder here called sock 101. And this is basically where I'm going to store all of the virtual machine information for the course. And so I'm just going to open up another explorer window here under the downloads folder and then locate the actual ISO file and just drag it into this sock 101 folder. All right, there we go. And so now let's open up Virtual Box and then click on the new button here within this main toolbar section. And from here we can start to fill in all the information about the Windows virtual machine we're creating. And so for the name, I'm just going to call it sock 101- Windows 10. And for the machine folder, well, I'm just going to override the default here. And so I'm going to click on other and then locate the sock 101 folder under virtual machines that I just created under documents. So I'm just going to select that folder. And for the ISO image, well, as expected, this is where we're going to locate the actual ISO file that we just downloaded. So again for me that's going to be under documents virtual machines sock 101 and this ISO file right here and when we do that it should automatically recognize things like the addition and type in version and so that all looks good to me and so next I'm going to make sure that I check skip unattended installation here and then I'm just going to click on next. Now, for a RAM or memory size here, it's technically possible to keep it at the default here of 2 gigs, but I can anticipate that you're going to run into some limitations. And so, if you have the capacity, it's best to bump it up a bit. And I have quite a bit of RAM on my physical host, and I'm actually running a VM inside of this. And so, there's a bit of VMion going on, but on my physical host, I have 32 gigs. And so, again, it all depends on what your max capacity is. And we're eventually going to be running two VMs at once. And so if you can bump it up to around 6 or 8 gigs each, well that would be great, but it shouldn't be the end of the world and we can always bump it up later if needed. And so next we can add a virtual hard disk to our machine. And specifically, we can create a virtual hard disk and we can keep our disc here dynamically allocated rather than setting aside the total amount of disc space needed immediately. And so to do that, just make sure you have pre-allocate full size unchecked. And for the storage amount, well, you can leave it at the default of 50 GB here if you need to. And again, if needed, we can always adjust these values later on. And so I'm just going to hit next here. And we will get a machine summary here. And this all looks good. So I'm going to hit finish. And there we go. So our machine's been created. And so our new Windows VM here is staged and ready to go. and to kick off the Windows installation, but we can just hit start here to start up our machine. This might just take a second. All right, and so here we go. So, if you saw that Windows loading screen and if you're now looking at the setup window here, well, then you've correctly set this all up. And a lot of the install process here is going to be pretty self-explanatory, but we can walk through it together. And so we can first select things like the language and the time and the keyboard input. And all that looks good. So I'm going to hit next. And then just click on install now. And this could take a moment to initialize. And we're going to be presented with the Windows license here. And so feel free to read through this if you want to take a nap. And we can just hit accept and then next. From here we can select the custom installation. And now we need to allocate the drive space. And remember this is all virtualized. And so what I'm going to do here is just click on new. And it's going to automatically fill the size of our drive. And so I'm just going to hit apply. And here it mentions that it's going to create some additional partitions which is fine. So I'm going to hit okay. We should see another partition there. There we go. And just hit next. And so now it's finally installing the operating system. And again, this could take a little while to complete. And so I'll just cut ahead to when mine's finished. All right. Now we should see this screen here. And it's going to mention that it needs to restart. And once we load back in here, we should see the main Windows installer. And so this is where it's going to ask us a bunch of setup questions and annoying little prompts until we can finally get to our desktop. And so I'm just going to run through this quickly. We can select our keyboard layout. This looks fine. We do not need to add a secondary keyboard layout. It's going to do some networking shenanigans or I guess magic they call it. Now again, this is going to be a lab machine, right? And so we can kind of skip all of the standard employee or the intended user setup features that Windows always asks for. And one of these is to sign in with a Microsoft account. And I think not. So let's click on domain join instead. And from here, we can set up a local account. And so for the username here, I'm just going to call it TCM. And for the password, I'm going to use the super strong password of password. And then we just need to fill in some security questions. So my first pet was named one, my childhood nickname was two, and and the city where I was born was three. And so now we can turn off all of this dystopian you know spying and tracking and privacy enrichment features that Microsoft is offering. And with that we can just click on accept. We can ignore Cortana here. So just click not now. And in a moment after this little message here we should be ready to go. All right. And if you see this Windows desktop here with this nice blue bright wallpaper, well then we're good. We're good to go. We're set up. And now there are a few more housekeeping things that we should do and we have to do before we continue. And the first being, well, let's get a bit of a quality of life improvement up in here. And so we're not stuck using this tiny croppedin box for our desktop. And so to do this and use an actual usable resolution, what we can do here is go under devices and click on insert guest edition CD image. And this is going to load in an actual CD drive into our VM. And so what we can do after clicking on that is go under our explorer window here and then click on this PC and we should see this CD drive for Virtual Box guest editions. So I'm going to double click on that to open it up. And from here, I can just double click to run this VBox Windows Edition- AMD 64. So, I'll just run this, hit yes, and just run through the very basic installer here. Just leave everything default. Should take a second. All right, sounds good. And we're just going to reboot now after doing that. And when we return here, the VM tools is going to start up as a service and we should be able to do some more interesting things, more interactive things and more, you know, visually pleasing uh, you know, integrations within our VM here. So, I'm just going to sign in. And so now what I can do here is go under the view tab and click on full screen mode and just hit switch. And there we go. That looks much better. Awesome. And the other thing that we can do now is so now our toolbar is going to be at the bottom here. And I'm going to go under the devices tab and go under shared clipboard. And then I'm going to change this from disabled to birectional. And so this is going to allow us to essentially share the same clipboard between our host machine and our Windows VM. And so that's going to be really useful when we want to copy and paste commands, you know, from our host into our VM or copy and paste output from our VM into our host. And so just to prove that it works, I'm going to open up the Notepad application here. And I know you can't see this right now. That's off screen, but I'm just copying the phrase hello world into my clipboard. And if I paste it, well, there we go. And for example, if I just copy the word hi here, and again, you can't see it, but I can paste this back into my host machine. And so our VM now is a lot more usable. And lastly, before we move on to customizing this install, well, let's take a snapshot of our base image. And this is really important in case you need to revert anything on your system or if anything goes wrong throughout the course. Well, you can always then just revert to your base image and not have to go through the entire install process again, right? And you can be confident that your VM is set up and in a state that's ready to go. And so to do this, I'm going to go down to our options here and click on machine. And then I'm just going to click on take snapshot. And I'm just going to title this base-install so I can reference it later. Hit okay. And now our VM is going to freeze up for a second just as it's taking the actual snapshot, which is all good. And so that's all finished. And with that, we now have our base image and we're ready for the next steps. Okay, so in a previous lesson, we installed our base Windows image that you can see here. However, to get ready for the course, we're going to need to do a couple of quality of life configurations and also get our course files onto the machine. And so, let's start up our Windows 10 VM again if you don't already have it running. And once we're loaded in and we're on this lovely desktop screen here, well, what we want to do first is some things that we would honestly never want to do if this was a real production system in the enterprise. But in the case for our lab environment and being able to interact with our Ubuntu VM and set up some really cool attack and defense scenarios, well, we're going to turn off Windows Defender, our sort of built-in endpoint antivirus. And again, this is because we're going to be creating some very basic malware later on in the course so that we can see what kind of artifacts it leaves on our system. And if we don't do this step, then Defender is going to get in the way and be really annoying and basically just yell at us a ton, which is nice. I really appreciate it. But for the case of trying to showcase some safe examples of malware, it's not really ideal for a use case. And to demonstrate that, well, I can just open up a PowerShell window here. And you don't have to follow along. Don't worry. I'm just kind of demonstrating here. And within PowerShell, well, I can just run the invoke mimikats commandlet. And don't worry if you don't know what mimiats is. We're going to talk about it later on in the course. Just know that it's bad. And even if I try to run it, I don't even have Mimiats installed on my machine, but it's already yelling at me that this script contains malicious content, even though the script doesn't even exist. It's already been blocked by again Windows antivirus. Another way to demonstrate this, I'm just going to open up my browser here, and I'm going to do a search for the EIC test file. And this is basically a test file developed specifically to test out things like the response of antivirus programs. And it's completely harmless, but Windows Defender should kick in and pick it up immediately and say, you know, hey, this might be malware as soon as we try to download it. And so what I'm going to do is scroll down to the EIC.txt file and I'm going to try to download it. Smart screen is probably going to yell at us and so I'll click on more information and just click on continue. And this is it. This is the malware that uh Defender is already piping up against. And so I'm just going to rightclick and save as and just try to save it to my downloads folder. And immediately we got an alert that Microsoft Defender found threats and this file should not exist anymore. Yeah, there we go. And so to disable Windows Defender, well, first what I'm going to do here is go under the Start menu and type in Windows Security. and I'm going to click on the Windows security application and go under virus and threat protection. From here, I'm going to go under virus and threat protection settings and click on manage settings. I'm going to scroll down to tamper protection and just check it off to turn it off. We're getting a warning here that our device may be vulnerable. That's okay. And what we want to do now is open up a PowerShell window as administrator. And so to do that, I'm going to go under the start menu. I'm going to do a search for PowerShell. And when we see the PowerShell application, we can either rightclick and click run as administrator or go down here and just click on run as administrator. We just hit yes to this UAC prompt. And we're now in PowerShell as an administrator. And from here, we just need to run a couple of commands, which fortunately now we can copy and paste. And I'll have them listed down below. The first one here is going to disable the real-time monitoring features of Defender. And this next one here is going to disable the scanning of network files. You can see we're already getting notifications that Defender has been turned off. And then a couple more commands here. And lastly, we're going to add a key to our registry to actually turn off Windows Defender. And so this is a long command, so you don't have to type this out. Again, you can just copy and paste. And to paste into PowerShell, you can just rightclick if you have something on your clipboard. So I'm just going to run that. We can see it completed successfully. And now if I search Windows security again in the start menu, go to virus and threat protection. And you can see we have no antivirus provider. So now what I can do is open up PowerShell again. Again, you don't have to follow along here. I'm just kind of demonstrating that we can now run invoke mimicats. And this is not going to do anything. So, we're going to get a different error, but it's not going to be the same error that it was, you know, disabled or blocked by our antivirus. And so, that is a plus. And if I return to this EIC file, click on continue, and just rightclick save as, we should be able to save it now and open the file with no issue. So good. That's great. And so next, with that out of the way, we can go ahead and actually get our course files onto the system. We didn't need to disable Defender to get our course files on the system. I'll just make that clear. But it's for stuff that we're going to be doing later on in the course. And so to do this, we're going to need to install Git, which is the version control system that we're going to be using to clone the course repository from GitHub. And this is all kind of in an effort to make sure that we're starting with the latest files in case anything changes over time. And so what I'm going to do here in my browser is go to git-cm.com. We're now on the web page for the Git version control manager. And under the latest source release here, you can see in my case 2.45.2. I'm just going to click on download for Windows. And then under standalone installer, I'm just going to click on the 64-bit for Windows setup. Once that's downloaded, I can just open up the installer file. Hit yes. And I'm just going to leave everything as the default option here. So, I'm just going to run through this installer. Everything looks good to me. If you wanted to, you know, you can read these options and make sure, you know, you're not signing away your life or anything like that. And it's now going to install All right, so Git's been installed. I'm going to uncheck view release notes. Don't really care. And now what we can do is run the git command in our command line and actually clone repositories. And so to do that, I'm just going to type in cmd to open up the command prompt. And from here, you can see I'm in my cuser/tcm directory. I'm going to go into my documents folder. So, I'm going to CD over into documents. And now I'm going to clone the course repository. And I will have the link to this repository down below if you want to check out the individual files. But we're going to be cloning the entire thing. And so what we can do here is just run git clone and then paste in the link to the git file and just hit enter. And that's just going to take a second to download. And there we go. And so now with this newly downloaded folder, well, we can unzip the course files onto our desktop. And so to do that, I'm going to open up an explorer window just with this little folder explorer icon here. And go into the documents folder. And we can see this sock 101 folder here. Well, this is the git repository that we just cloned. And can see all of the different files and folders within this. And so I'm going to open up the course file directory here. And you can see we have a number of zip files relating to each domain or section in the course. And so all we need to do now is just extract each of these folders so we get access to the contents inside. And so all we need to do is just select the first file here, right click on it, and then I can click on extract all. And what I can do is change the location of the extracted files. And so I'll click on browse, and then I'll just send it over to the desktop. So I'll click on desktop and then select folder. I'm just going to uncheck this to show extracted files when complete. And then I'll just click on extract. And all we need to do now is just repeat that same process for the remaining files. So I'll right click on this one, extract all, send it to the desktop, extract, and repeat. All right. And so with that done, if you wanted to, you can just organize them the way you want to. Or you can create a folder here on the desktop. And I can just call this something like sock 101 course files. And I can just move that up to the top here. And just highlight and drag in everything into this folder just so it's more organized. And within this containing folder, well, you can in fact see we have all of our course files and directories. Nice. And to make our lives easier, you don't have to do this step, but I will just show it just in case. I want to add PowerShell and the command line as shortcuts on my desktop just cuz we're going to be accessing them a lot. And so to do that, I'm just going to go down to the start menu here and type in PowerShell. I'm going to right click on the application and click on open file location. And from here under Windows PowerShell, I'm going to rightclick, go under send to, and then select desktop to create the shortcut. There we go. So, we have PowerShell. And now for the command prompt, I'm just going to type in cmd. And once again, same thing. Open the file location, right click on it, go to send to desktop. Nice. And with that, well, we're now good to go with our Windows VM. We're going to install a number of different things and tools as we go throughout the course, but for now, we have our base image and our base installation ready to go. All right. And so now back on our host, we can go ahead and install our Linux machine. And the flavor or the distribution of Linux that we're going to be using is called Ubuntu Linux. And so I'm just going to open up my browser here and do a search for Ubuntu download. And we should see this get Ubuntu link here. And I'll have it linked down below. And from here we can go under the desktop version because we want to have that graphical user interface or that desktop environment and then click on download Ubuntu desktop. And from here what we can do is download the long-term support version or the LTS version here. And for reference in my case the release number here is 24.04. And if you need to find older versions for example if you're not seeing the 24.04 04 link here. Well, you can go down to check out our alternative downloads link. And from here, just go down to past releases and click on all past releases. And from here, you can go through this repository here of all the different past versions. However, we don't need to do that. So, I'm going to go back. And from this download page here, I'm just going to click on the green download button. And within a second, it should start downloading. And so again, this is a 6 GB file. And so just be patient with the download and let it transfer over. And once it's complete, I'll see you again for the next steps. And now that we have our Ubuntu ISO file downloaded, well, we can head back to Virtual Box and create our new VM. But first, what I'm going to do is some more organization here. So I'm going to go under my documents, virtual machines, and the SOC 101 folder. And I'm going to open up a second window here to my downloads folder and just drag over that Ubuntu ISO file into this sock 101 folder. All right. And so from here, I'm just going to open up Virtual Box. And from the main page here, click on the new button. For the name, I'm just going to call it sock 101- Ubuntu. For the folder again I'm going to update this do point to documents virtual machines sock 101 for the ISO image of course that's going to be our Ubuntu ISO file and we should be good to go and so again I'm going to check off skip unattended installation here and hit next and so again same kind of deal here like with Windows and so allocate as much memory as you can here to reasonably run both VMs at the same time alongside ongside your host. And to be honest, you can kind of strategize here and sort of overresource your Linux VM first since we're not going to be working with our Windows VM as much during the first section or two. But then once we start working with Windows more, you can then reallocate your RAM. And so I'm going to set my RAM to around 8 gigs here. And for the processors, going to bump it up to two. For the storage space, you can leave it at default, but I would recommend we kind of match our Windows, you know, storage here. And again, make sure you have pre-allocate full size unchecked. And we can just hit next. Review everything. Make sure it looks good. And I'll hit finish. All right. And so now we have our two virtual machines ready to go. And now we just need to run through the installation process for our Ubuntu VM. And so I'm going to click on the green start icon here. And it's going to start booting everything up. All right. And when this starts up here, we can just leave it as is. You can see it's counting down. Or we can click into the actual machine here, click on capture, and then we can select the different options. And so I'm going to keep it at the, you know, first selection here at try or install Ubuntu and hit enter. And if you see this loading screen here, well then you're good to go so far. And from here, we can just run through the installation process. And so we can choose our language. Hit next. We can turn on some accessibility settings if you need to. We can set the keyboard layout, the internet connection. It's going to say there's an update. You can either update now or we can do it later. And from here, we're going to keep it on install Ubuntu. And then hit next. And we'll keep it on interactive installation and leave it again on default selection here. For the recommended proprietary software here, we can just ignore this for now. And for the installation screen, well, we can leave it again on erase disc and install Ubuntu. And don't worry, it's not your host disc that's going to be erased. It is the virtual hard disk that we just created. And so I'll just hit next. We can set up our account. And so I'm just going to call my account TCM. Of course, for the computer name here, I mean, you can set this to whatever you like. I'm just going to call it sock 101. Again, for the username, just call it TCM. Password. The very strong password of password. Once again, actually for the computer name, I'll just change this to sock 101- Ubuntu just in case when we're looking at it in the logs, we can actually, you know, differentiate it and then hit next. We can select our time zone and review all of our selections, which looks good to me. So, I'm just going to hit install. And so, now it's installing the actual operating system. And so, like with everything here, this could take a little bit. And so, we just need to wait for it to finish. All right. And so, that install finally finished. We can just hit restart. Now, it's going to ask us to remove the installation medium. And so, essentially just eject the ISO file, but Virtual Box should have done this automatically for us. So, we can just hit enter here. And we're now going to be taken hopefully to the desktop. And there we go. And so we can see the login screen here for the user TCM. Just going to type in my password. And there we go. And so if you're seeing this message here, well, you successfully installed Ubuntu Linux. Now, like we did with Windows, let's get our Ubuntu machine looking better by installing the guest editions image so we can increase the screen resolution and allow for things like the shared clipboard. And so to do this, we can open up the terminal window. And I'm just going to right click anywhere on the screen and click on open in terminal. And this is going to open up the terminal window, which is a lot like the command line in Windows. And so from here we can just run the clear command to clear out that warning message. And the first command we want to run here is pseudoapp update. And this command and argument like the name suggests is going to update all of the system package well on our system. And so I'm just going to hit enter there. And it's going to ask us for a password because we're invoking this with pseudo. And so we're running it with elevated permissions. And so if you run into this yellow warning here about the unit file like I did, well, we just need to run this command here. So systemct ctl damon reload. And we want to prepend it with pseudo once again. So pseudo systemctl damon-reload. So there we go. And so now what I can do is just hit the up arrow twice to run our pseudo apt update command once again. And there we go. It looks like everything is running just as expected. And from here, we need to install a couple of required packages before we can actually install the guest edition CD. And so the command we're going to run here is pseudo apt or a install. And then the packages we need to install are the following. Bzip 2, tar, gcc, make, pearl, and lastly, git. And I'll have all these commands listed down below. We just can't really copy and paste them yet because we don't have our, you know, shared clipboard ready to go. And so I'm just going to hit run. And when we run this, it's going to ask us if we want to continue. And so I'm just going to press shift Y here to put in a capital Y and hit enter. And those packages have now been installed. The next command I'm going to run is pseudoapp install linux- headers-g generic. And this is going to install the generic kernel headers, which again is kind of high level, but it's something we're going to need to actually install the guest editions image. And now what we can do is run the same command again, but I'm just going to modify the end here after the last dash here. and basically just run a subshell with the dollar sign and then within parenthesis here I'm just going to run the uname command with the tac r option to essentially just sub in here our own kernel version and you might see this message here that we already have you know the newest version and that's all good and so now what we can do I'm just going to minimize our terminal here I'm going to go under devices and click on insert guest edition CD image when we do that we should see this little CD icon appear I can just click on that and we can see we have a actual directory structure mapping to this CD. And so what I'm going to do is open up our terminal again. Again, that's just going to be on the left, you know, side navigation here under this little terminal icon. And I'm going to CD or change directory over to the / media directory. Okay. And if I run an ls, we can see the directory for my user TCM. So I'm going to hop into there with cdtcm and then run an ls and we can now see the virtual box image. And so again I'm going to change directory here into that actual directory structure. And so I'm just going to start typing it with vb here for vbox. And then I'm going to hit the tab key and it's going to automatically fill in the name of the directory. So I'll just hit enter. And if I run an ls we can see a number of different files. And specifically this is the one that we want to run. This vbox linux additions.run. run file. And so to run this file, I'm just going to run pseudo with a dot slash here and put in the name of the file. And that's going to be vbox. I'm just going to start typing in Linux and just hit tab. It's going to autocomplete there. And then I can just hit enter. And that's going to start installing everything it needs to. And you can see it actually kind of shrunk our resolution here. So, I promise I didn't just troll you. This is part of the process. And so, what we need to do is just restart our VM now. And so, I'm just going to run pseudo reboot and then just give it the now argument to make sure it reboots right at this very moment. And now that we're back in, what I can do now is go under the view option here and click on once again full screen mode. Just hit switch. There we go. That's looking much better now. I'm just going to sign in here. Make sure everything is going well. Make sure everything's good. Nice. There we go. And so again, our toolbar here is now going to be on the bottom. And what I can do is click on devices, go under shared clipboard, and once again, make sure that's birectional because it's going to really save a lot of time and a lot of typos uh when it comes to, you know, copy and pasting commands or outputs back and forth. And just to demonstrate this, I'm going to rightclick, click on open in terminal. And again on my clipboard, I have hello world from my host. Going to paste that in. Looks good. And to double check it's working, I'm just going to copy this. And I know you can't see it, but that pasted in no problem on my host. All right. And so with that, we now have our Ubuntu VM ready to go. And our lab is starting to come together. And so I will see you in the next lesson. All right, now it's time to actually configure our Ubuntu machine. And we just have a couple of things to do. And so first, let's make sure we have git installed so we can clone the actual course repository. And we did install it earlier. I just want to make sure that it is actually installed in case you didn't run, you know, one of the commands earlier or something. Let me just zoom in for you. I'm just going to type in which git and this is going to locate the actual file itself or the binary. And fortunately we do have it. But if you don't, you can just run pseudo apt install git. Type in a password. And you can see in my case I already have it installed. All right. And so now I'm just going to head into the documents folder. So I'm going to give it the tilda here to go to my home directory. and then with a slash type in the documents folder. And from here, I'm going to clone in the course repository. And again, I will have this command linked down below with the URL and everything, but it's just going to be a get clone command here. And then pasting in the actual URL of the git file. So, if I hit enter, we're going to clone this into its own directory. I run an ls, you can see we have the sock 101 directory ready to go. If I just run an ls inside of it, well, we are good to go. And so what I'm going to do now is open up a file browser. And that's just going to be this folder icon here. And I'm going to head to my documents folder under the sock 101 folder that we just cloned. And I'm going to go into course files here. And within this directory, what we can see a zip folder containing all of the course files for each domain in the course. And what we need to do now is just extract each of these folders. And you can either extract them all at once, which I'm going to do, or you can extract each of them one at a time as you make it through each section in the course. However, the process is going to be the same no matter what. It's just a little repetitive, and I'm sorry about that, but it really makes the course more modular, so I can update each section as time goes on. And so what I'm going to do is just select and highlight everything here. And I'm going to right click on one of the files and click on extract. Excellent. So there we go. And so we have every zip file here, which we don't actually need anymore along with the corresponding extracted folders. And with them all highlighted, I'm just going to drag them all to the desktop. I can close out of this folder here. Excellent. And there we go. And so that's starting to look a lot better. All right. And what I also like to do is move this side navigation down to the bottom like kind of like a more standard Windows desktop environment. Again, totally optional, but if you want to do it, we just need to right click anywhere on the desktop and click on desktop icon settings. And from this window here, just need to scroll down to position on screen under the dock and change this from left oh to bottom. And there we go. And we can also start to clean up the different items on our taskbar as well or our you know doc bar. And so the first thing we can do is right click on the actual CD icon here for the guest editions and just click on eject from this little help window here. We can unpin this again by rightclicking. Same kind of deal with the app center here as well. And what I will do is pin the terminal icon to the dash because we're going to be using it quite a bit. And that looks good to me. And so with all of that out of the way, there is an install script located in the course repository that we need to run to install any necessary packages or dependencies before we start jumping in. And part of the reason why we have this repository is in case I need to update the list of packages that is included in this install script, right? If I need to include any additional packages later on. And so if that's the case, well, it's easy because the process doesn't change for you. I just need to update the script on my end. And so I'm going to open up the terminal here. and I'm going to head to the documents folder. So, I'm just going to CD back into my documents folder here and I'm going to go into that sock 101 directory within my documents folder. And then I'm going to go into resources and then into the install directory. And if I run an ls, you can see we have this install.sh script. And so to make it executable, we can run the change mode command or chmod. Give it the plus x to add that executable bit and then provide the name of install.sh. And now if I run an ls, well, it should be green. There we go. And so now I'm just going to run the file with dot /install.sh. And it's just going to update our packages and just install a couple of things. So it shouldn't take long at all. And just like that, the installation has been completed and we are good to go. And so lastly, this is completely optional once again, but I'm going to be super slick here and just update the desktop wallpaper. And so to get there, I just rightclicked anywhere on the desktop and clicked on change background. And from here, I'm going to go down to background and click on add picture. I'm going to locate under documents the sock 101 folder. Go under resources under the wallpapers directory and click on wallpaper.png. png. And I'm just going to click on that there. And now we're looking a lot better in my opinion. However, this did kind of mess up my ordering here. So, I'm just going to fix this. All right. And so now we're good to go. We just need to do a quick networking setup and then we're ready to jump into the course. Now lastly, we just need to make a couple of networking configurations between our two VMs that will allow them to talk to each other but not to our physical host. And this is important to ensure that you know both our VMs are physically separated from our host but logically connected to each other. And to do this in Virtual Box, we just need to create a network and then apply it to the network adapters for our VMs. And it kind of sounds complicated, but it's really easy. And so under tools here, I'm just going to click on the little hamburger icon here and go down to network. All right. And from here, I'm going to click on the NAT networks tab. And then I'm just going to click on create. And now with our sampleN or network address translation network created, well, I can right click on it and go to properties. And from here, what we want to do well is first name it. So I'm just going to call it TCM. And next we need to set the IPv4 prefix. And so this is basically going to be the network range that our network is going to utilize. And you can leave it at 10.0.2.0 here if you want. It doesn't really matter. And best practice is to keep the actual range here separate from what your physical host is using. Or in other words, make it look different. Right? So if my host machine is using 192.168, you know, well, I can make my NAT network here 10.0.2. And so they just kind of look visually different. But anyways, in my case, what I'm going to do is just change this to 192. And feel free to follow along. Again, it doesn't really matter. It's just that anytime I reference my own IP range during the course, well, yours might be different if you set something different here. And that's fine. Completely fine. Just keep that in mind. So 192.168.1.0. And again, I'm just going to make it a/24 network. Going to keep DHCP enabled. And that's basically it. So, I'm just going to click on apply. Now that that's ready and created, we just need to tell our two VMs here to use this network. And so, I'll start with the Windows machine. I'm just going to right click on the actual VM name here and go to settings and then go down to the network tab. And the first thing I want to do here is click through all of these different tabs here, listing out the different network adapter cards. And I just want to make sure that none of them are checked aside from adapter one here. And under adapter 1, I'm going to make sure it's enabled, obviously. And under attach, I'm going to change this to NAT network. And under name here, I'm going to make sure it's set to TCM or whatever you just named it. And that's all good. I'm going to click on okay. And I'm going to do the same thing here for my Ubuntu machine. Go under network again. Make sure none of the other adapters are selected. and under attach to net network and make sure it's TCM. And there we go. And so if you want, we can verify connectivity here. So we just need to spin up both machines at the same time. And so we can just click on start. All right. And with my two VMs running, you can see I just have them on different windows here. I'm going to start off with my Ubuntu machine and open up the terminal so I can get my IP address. And with the terminal open, I'm just going to run the if config command. And so if I just hit enter, you can see I'm getting my IP address here under ENP03 under inet. You can see my IP address is 192.168.13. Over on Windows now, I'm going to open up the command prompt. And this time I'm going to type in IP config. And you can see that my IP address is 1 192.168.1.12. And so on Windows we have.12 and on Ubuntu here we have.13. And so that's a good sign. It looks like they might be on the same network. And so what I can do now from my Windows host is try to ping the IP address of my Ubuntu host. And if I get a response, well, it means they can in fact communicate. And so that's just going to be ping and then the IP address. And remember, your IP addresses here might be different, and that's completely fine. Just make sure you're using the right one. Don't just use mine if yours is different. In that case, you're not going to get the result that you want. And so I'm going to type in 192.168.1. And my Ubuntu host ends in 13. And so if I run this, you can see we are in fact getting replies from our host, which is a great sign. And just a note here, I'm pinging my Linux host from my Windows machine. If you try to do it the other way around and ping your Windows machine, well, the pings are going to fail because by default, Windows machines block pings or ICMP traffic. You can resolve this by going into the Windows firewall and allowing IPv4 ICMP packets. But don't worry, we don't need to do that. If you're getting pings back from your Linux or Ubuntu machine, then you're good. And the two systems can talk to each other. And so there we go. So we've finally set up our VMs. We've configured them, customized them, and now we have the networking set up, too. And so, thank you for following along for this lab setup. I know it was quite a bit, but now we get to jump into the fun. And so I will see you in the next lesson. Before we get into the main practical sections of this course, let's first understand what a sock is, the components that make up a sock, as well as some important terminology that we should be familiar with. Now, I have a confession here, and it's that this section of the course is going to be a bit of a death by PowerPoint section. And I'm really sorry in advance, but trust me, every other section of this course is going to be hands-on and practical. It's just that it's really hard to present some of this stuff in a less theoretical way. But I promise you that this is the only section that is going to be very slideheavy like this. And trust me that this is going to lay a necessary foundation that we're going to build upon to grasp some of the hands-on topics. So within this section, we aim to gain a holistic understanding of security operations within organizations that you might find yourself in. So when we talk about the domain objectives for this section, we want to understand the core functions within a sock as well as the role that it plays within organizations. So we want to answer questions like why do we have a sock and what is the business justification for maintaining a sock from a resource or financial aspect. We also want to explore the daily tasks and responsibilities of a sock analyst. We want to understand what the day-to-day looks like in an average sock. We also want to familiarize ourselves with different sock models, roles and organizational structures. You know so how is the team actually structured and how do various roles and responsibilities disseminate amongst the team. We also want to learn several metrics that are used to evaluate the effectiveness of our security operations. Right? So what does success look like for a sock team and how can areas of improvement be identified. We want to understand various tools that are used within the sock for monitoring, detection, analysis and response. And lastly, we want to identify and understand common cyber security threats faced by organizations because of course as our technology landscape grows, so does our attack surface. And we need to be able as sock analysts to quickly identify common threats. So the first question we should probably ask is what is a sock? Well, a sock is short for a security operations center and you're going to see many different definitions of socks out there. You know, some sources might define a sock as the heartbeat of an organization security posture. And some sources might describe it as the frontline defense against cyber attacks. And all of these are essentially true. And part of this reason, and something that's continually going to come up throughout the course, is that socks can vary greatly between organizations based on their size or industry or budget or maturity level. But regardless of the terminology used, the core essence of a sock remains the same. A security operation center is a centralized unit within an organization that deals with security issues, incidents, and events. And this definition casts a wide net. And that's kind of purposeful because socks serve many different areas of the business which we're going to cover shortly. But the primary objective of a sock is to minimize the impact of cyber attacks and protect sensitive data and to ensure the confidentiality, integrity and availability of the organization's assets. And so of course a sock is going to be staffed with a team and that team is going to consist of security analysts and engineers and incident responders and basically a number of people that collaborate together in order to monitor, detect, analyze and respond to cyber security incidents in real time. So let's cover all these different stages in more detail. So the first step in any security operations is monitoring and that involves continually observing the organization's networks and systems and digital assets for any signs of suspicious activity. And so we use things like our monitoring tools and technologies like our SIMs, our security information and event management systems or our IDS or intrusion detection systems. And we use these tools to provide real-time visibility into things like our network traffic or log data. For example, suppose a sock team has deployed an endpoint detection and response solution like Crowdstrike Falcon to all of the company's servers and workstations and we use it to track things like file access or suspicious processes or login attempts. And so once potential security incidents are identified through our monitoring, sock analysts employ various detection techniques to confirm the actual presence of threats. So this might involve things like correlating multiple security events together and searching through our SIM to analyze patterns of behavior based on the logs or statistics or even threat intelligence feeds to identify known indicators of compromise or IOC's. So to continue our example, suppose an alert is triggered within our EDR software, signifying that an employee, Bob Jones, is attempting to access sensitive files outside of their normal working hours and location. So in that case, we're actually analyzing Bob Jones's behavior on his system, and we're noticing, hey, this is an anomaly. You know, Bob Jones typically operates between 9:00 to 5, and in this case, it's 3:00 a.m. his time. Why is he trying to access files at this time? And so we're going to get an alert on that. and we're going to detect the event. And so here we move on to the analysis section. This is where analysts conduct in-depth investigations to understand the nature and scope of the incident. So this will involve things like examining the affected system or analyzing malware samples or tracing an attacker's tactics, techniques, and procedures or TTPs to determine the extent of the compromise. So in the case of our EDR alert, an analyst would need to investigate the alert to get more information. They might have to review Bob Jones's access history, right? His recent login, the IP addresses of these login to see if there's anything anomalous. We might need to look at other data points that we have available to us to determine if that access attempt is malicious. And next, we have response, right? So based on our findings, sock analysts need to formulate and execute a response plan to contain the threat or mitigate its impact and restore normal operations. So this might involve things like isolating the affected system or deploying patches or updates or coordinating with other internal teams like stakeholders or even law enforcement or regulatory bodies as needed. So to wrap up our EDR alert example, maybe after thorough investigation, we as an analyst find that Bob Jones's access attempt is in fact malicious, in which case we need to respond and mitigate the threat and contain the threat and do things like revoke Bob Jones's access. we would need to reset his credentials and maybe look through our sim to see if we can correlate other events and try to figure out the root cause. We might need to inform relevant stakeholders and conduct a deeper investigation. And lastly, you can see here on the right how this all sort of works together and feeds into each other within this life cycle. So, as we're able to improve our monitoring, we can then detect more incidents. And as we analyze these incidents, we're able to have more effective response. And through everything we've learned through our response and all of the indicators that we've collected, we can then feed that back into our monitoring to enhance our detection capabilities. So you can see how this all sort of feeds into each other and they all build upon each other. So when we say that a sock is centralized, you might be picturing in your head something like the image on the screen here where we have a giant bustling room filled with rows and desks and a bunch of analysts sitting shoulder-to-shoulder and hundreds of monitors at the front all displaying intricate graphs and charts. And you know, an image like this has long been the common depiction of a sock in many people's minds. However, as the modern sock has evolved, especially in the wake of things like the rise of remote work and the digital transformation of businesses, well, this sentiment is no longer as common. Instead, the concept of a centralized sock has kind of undergone a transformation. So, rather than a physical room housing a large team of analysts, today's sock is increasingly virtualized and distributed in many cases. And you know with the advancement of cloud technologies and things like virtual private networks and collaboration platforms well now sock teams are able to operate from almost anywhere in the world without the need for a centralized physical location. However, the sock still logically refers to that centralized team within the organization. And we can also take a step back in time and understand how the concept of a sock has evolved over time. And maybe in doing so we can better understand how the priorities and the functions within a soach have shifted to meet the changing landscape of threats and challenges. But at a high level we've essentially seen changes from a primary focus on just availability monitoring to more reactive monitoring. And from there we've moved on to proactive monitoring and now to proactive automation. And so the initial concept of a sock well started well before the 2000s and traces back to the early days of network security primarily with government and defense organizations. In fact, we can go all the way back to 1975 with the United States National Security Operations Center. And this picture is so cool because it laid the groundwork for what would eventually become the modern sock because back then every security solution and control and tool was customuilt to detect very specific threats. and most commonly back then were dealing with availability issues and malicious code running within a network. But during the late '9s and early 2000s, cyber threats kind of evolved and organizations began to recognize the importance of fortifying their digital perimeter. And the emphasis shifted from initial availability monitoring towards perimeter defense with companies spending investments in technologies like firewalls and antivirus software and intrusion detection systems. But the focus was still largely reactive and sock teams were more so responding to incidents as they occurred. But of course, the landscape of cyber threats continued to evolve. And around 2007, we saw the rise of advanced persistent threats or a kind of introduced a new breed of attacks that haven't previously been seen before that operated in this low and slow type of environment and evaded traditional security methods. And these types of attacks meant that an adversary could be in your network for months or even years without any detection. And they could quietly excfiltrate data or start laying the groundwork for more large or devastating breaches. And so this prompted a transition from reactive to proactive monitoring within sock environments. And this is sometimes referred to as the age of the SIM or the security information and event management systems, which we'll get into much more detail later on. This shift in mindset laid the groundwork for what is today the modern sock which adopted more of a proactive stance towards cyber security. So rather than just reacting to incidents, sock teams began to actively monitor for signs of potential threats and using things like threat hunting techniques to proactively hunt for evil. And you know there are several other generations of sock history that we didn't get into, but I don't think it's that important. You know, the main takeaway here is that there was a shift between reactive perimeter defense to proactive threat detection and response. And so, what actually makes up a sock? You know, it's not just a magical entity or concept that CISOs love to brag about and vendors love to sell products to. There are actual tangible things that make up the team and its capabilities. So, every sock is equipped with personnel, with protocols, and technical resources that all work together to cover the functions that we've talked about earlier. And you know, we mentioned personnel and protocols and technical resources, but let's break that down a bit because they are essentially the definitive pillars that make up a sock. And another way that we can think of this is through people, processes, and technology. So, of course, we have people. These are the personnel within the sock that form that human element or that backbone of operations. And often this human element is crucial in ensuring how effective a sock can be. This personnel includes people like analysts and incident responders and engineers and threat hunters who all work together to actually analyze, respond to and resolve security incidents or do things like build out detection capabilities or manage the team. We also have processes. So teams also need to build out descriptive processes that streamline their operations and ensure consistency, efficiency, and agility to manage and respond to incidents. So you might have specific incident response playbooks or detection and response processes that the team can follow during the life cycle of an incident or event. For example, when an alert is triggered, well, what predefined processes or procedures are in place to dictate how the sock responds? You know, what escalation paths are there? What investigation steps or mitigation measures can be taken? Of course, that's not an exhaustive list, but just understand that processes drive the way in which people within the sock conduct their operations. Lastly, we have technology. And technology provides the tools and infrastructure necessary for the people within the sock to do their jobs and follow processes. And of course, this is a non-exhaustive list again, but concepts that fall into the technology category can include things like our SIM platform, our IDS or IPS systems, our EDR solutions, our soar systems, vulnerability management tools, or even our threat intelligence platforms. And of course, we're going to cover these tools and more in much more detail in the following lessons. and we'll also get to directly configure and interact with several of these tools to gain that hands-on experience with them in the following domains. Now, I also want to quickly touch on the concept of the CIA triad and how security operations centers use this model as a fundamental principle that basically guide every single practice decision and control that they make. And more specifically, the sock supports the business by upholding these principles of the CIA triad. So, we have confidentiality, we have integrity and availability. We're going to cover each of these in more detail in a future lesson, but at a high level, the sock aims to ensure the confidentiality, integrity, and availability of all assets within the organization. And we can think about how all of these concepts kind of intersect during an incident, right? So, for example, in the case of a critical server failing, maybe we had a hardware disc failure in one of the servers and we did not have redundancy in place. Well, in this case, we'd be facing an availability issue because we are losing access to the data stored on that server. So in this case the sock would rely on the people you know the experts that can leverage their expertise of skilled analysts and other IT personnel who understand the intricacies of the system and these people would then enact pre-established recovery redundancy or failover processes to mitigate the impact of the availability issue and lastly they would utilize technology solutions like automated backup software or redundancy failover solutions that can restore and bring up the affected server. And lastly here, let's take a look at some of the key functions of a sock. Right? So, we talked about what makes up the sock and the value that they add to organizations, but what specific objectives do they actually serve on a day-to-day basis? Now, this won't be an exhaustive list, but it's going to highlight some of the highle functions that a typical sock will perform within an organization. And we can generally break down the key functions of a sock into two distinct categories. We have reactive functions and proactive functions. So on the reactive side, these are functions that the sock performs in response to cyber security incidents as they occur. So we have things like the primary role of the sock monitoring and detection. So this is where the sock team is going to monitor network and system logs or endpoint devices, security alerts and other sources of data to identify potential security incidents and threats in real time. So we're going to use tools that we have available to us like our SIM platform, our IDS systems, our threat intelligence feeds or even manual log analysis. And next we have incident response. So when a security incident is detected, the sock is going to initiate an incident response or an IR process to investigate, contain, and mitigate the threat. So this is going to involve actually analyzing the incident and gathering evidence and coordinating with relevant stakeholders to minimize the impact and restore normal business operations. And depending on the size of the sock, you might have forensic analysis functions as well. You know, this could be something that's conducted inhouse or maybe coordinated with a third party that specifically does forensic examinations. But overall, this is going to include conducting detailed forensic analysis to determine the cause and extent of any security breaches. This is also going to include preserving and collecting digital evidence for any potential legal or regulatory purposes. And depending on the size and severity of the incident, the team may have to collaborate with law enforcement agencies or external forensic experts as necessary. And lastly, here we have malware analysis. And again, depending on the size of your sock, this is something that could be conducted in-house or coordinated with a third party. And this could involve running malware samples in controlled environments like sandboxes or VMs to understand their actions and potential impact on your systems or networks. It could also involve things like reverse engineering and deoffiscating malware to study its behavior. But the goal here is ultimately to collect indicators of compromise and attempt to attribute the malware to a specific threat actor or group to enhance your threat detection within the organization and inform more proactive defense measures. And speaking of which, we have proactive functions as well. And these are the functions that the sock performs to prevent cyber security incidents before they occur or to mitigate potential vulnerabilities. So we have threat intelligence and this is where the sock team actively gathers and analyzes threat intelligence data either from internal or external sources so they can stay informed about emerging threats or indicators of compromise vulnerabilities as well as other attack techniques. And of course the goal here is to feed that intelligence into our detection tools themselves so we can then enhance our detection capabilities and find incidents sooner. Which kind of leads us into threat hunting. So this is where the sock team is going to proactively search for signs of malicious activity or intrusions that might have evaded traditional security controls or detection mechanisms. So by performing specific hunts and analyzing logs and doing detailed searches, we attempt to identify indicators of compromise and potential threats that might be lurking within our environment that we haven't detected yet. And next we have vulnerability management. And some might argue that this could be under reactive or maybe a blend between reactive and proactive. And I wouldn't disagree because while it does involve reactively responding to vulnerabilities that are identified, it does so in a more proactive way to mitigate them and remediate them before they're exploited. But essentially, vulnerability management is when the team works closely with other departments like the IT team or the development team to identify and address vulnerabilities within the organization's assets. So this is going to involve performing vulnerability scans and assessments and identifying actual vulnerabilities and implementing things like patch management schedules and ensuring that the organization can remediate identified vulnerabilities in a timely manner. And lastly here we have security awareness training. So the sock personnel themselves often play a role in promoting cyber security awareness within the organization. So they might do things like educate employees on best practices or write up security policies and procedures and make sure that employees read them or even provide training to enhance the overall security awareness and help prevent security incidents in the future. They might even go as far as to simulate fishing attacks and gauge how effective the organization is in responding to them or falling victim to them. But ultimately the end goal here is to mitigate human error that often leads to incidents. Let's dive into a bit of a refresher on some of the important information security concepts and terminology that's going to come up time and time again throughout this course. And the goal here is not to just throw a bunch of terms at you for memorization, but to gently introduce some of the foundational concepts of what it means to work in a sock, but also some of these concepts might actually get thrown at you in interviews. So, it is best to have a solid grasp on them. But if you've been pretty familiar with everything so far, or if you have a background in security, well, you're going to breeze right through this section. And if not, don't worry because we're going to hopefully fill in those gaps for you here. So, let's start out with something we've briefly mentioned in the previous lesson, the CIA triad. And this triad is a foundational concept in cyber security that represents the three core principles of confidentiality, integrity, and availability. And essentially any security control or process or tool that you implement within your organization is aimed to protect one of these principles. So let's cover them a bit. Let's talk about confidentiality. And this is going to ensure that information is accessible only to those who are authorized to access it. And we can implement many security controls that focus on protecting the confidentiality of data. And most often you'll see it associated with encryption. So, if you're not familiar, that's going to be converting the data into a form that can only be read or processed after it's been decrypted using an appropriate key. Therefore, if someone who is not authorized or does not possess that key gains access to the encrypted data, well, they won't be able to read it. And honestly, we use encryption all over throughout our environments and even within the sock. For example, we're going to need to encrypt data stored at rest. Things like hard drives or backups or like log archives from our SIM or even data in processing in transit. For example, right now you're watching this video. You're accessing it through an HTTPS protocol, which is the web protocol that integrates TLS or transport layer security that introduces encryption within the connection. But there are other controls related to confidentiality as well. We can think about access controls like access control mechanisms like authentication and authorization processes. Basically, anything that can restrict access of information based on a user's identity, roles or any other attributes. We can also tackle this from a process side, right? So we have data classification for example. So we can classify data stored within the organization or within its systems based on its sensitivity level. For example, data might be categorized as public for internal use only or strictly confidential. You know this classification helps us determine the appropriate level of protection and access controls that we need for each type of data. Next we have integrity. And integrity ensures that the data remains accurate, complete and also unaltered during its storage, transmission or even its processing. So this is where we protect data from unauthorized modifications or deletions or insertions whether it's accidental or malicious. And this comes into play a lot actually during digital forensics where we need to document a proper chain of custody of evidence and be able to prove and present that the evidence that we submit has not been tampered with. And often we do that through hashing algorithms and things like write blockers to prevent modifications. We're going to get deeper into that of course during the digital forensics section. But we can also implement things like audit trails that keep detailed records of data access and allow us to track changes and allow us to identify any unauthorized changes. And lastly, we have availability. And this ensures that information and resources are actually accessible and usable when we need it. And commonly you'll encounter controls such as things that prevent disruptions or denial of service attacks because of course these compromise the availability of systems. But realistically, so many different things could be a disruption to availability. We can think about a server failing or an internal DNS or a proxy going down which prevents employees from accessing a certain website that they need or maybe accidentally implementing an oversensitive endpoint rule that's going to block access to an important business application. Next, we have the AAA framework which is also known as the authentication authorization and accounting framework. This is a model that is used to securely control access to resources and services and provides a more structured approach for managing user interactions on a system. And like with many of the controls we talked about, the ultimate goal of the AAA framework here is to ensure that only authenticated and authorized individuals can access specific resources. So we have authentication. And of course, this is the process of verifying an identity of a user or a system entity attempting to access a resource. Basically, it ensures that they are who they say they are. And we have different authentication methods, right? We have things like passwords or keybased authentication using public key infrastructure or even things like biometrics, right? fingerprints or facial recognition. And we can provide multiple sources of authentication at once to create more security or also known as multiffactor authentication. Next, we have authorization. And this determines what actions or permissions or what resources a user is allowed to access after they've authenticated themselves. And typically, this relies on defining an enforced access policy based on specific user identities, roles, or other attributes within the company. So we're looking at things like access control lists or rulebased access control. And lastly here we have accounting which is also known as auditing or tracking and it essentially it involves logging and monitoring user activities within the system. So it records details like who accessed what service and when for how long and often accounting is really crucial for meeting compliance standards, but it's also just as important for security event monitoring as well. And we can use things like native audit logs as well as monitoring tools like our SIM to record user activities and implement accounting. So next, let's make some important distinctions that often come up when talking about security operations. And sometimes the terms that we're going to cover here are used interchangeably, which is a common misnomer because they're related, but they have distinct meanings. So we have a threat, a risk, and a vulnerability. And let's talk about how they differ from each other. So to put it simply, a vulnerability refers to any weakness or a flaw in a system, a network, an application, any kind of asset that could potentially be exploited by a threat actor to compromise anything within that CIA triad, right? So we can think of things like software vulnerabilities, right? Coding bugs or coding errors or design flaws, uh maybe configuration weaknesses like improperly configured systems, default passwords or unpatched software. But there's also human factors as well, right? So human errors or negligence or even just a lack of awareness can lead to security vulnerabilities like someone falling victim to a social engineering attack. A threat on the other hand refers to any event or even an actor themselves with the potential to exploit vulnerabilities within any of the organization's assets. So threats don't have to just be a malicious individual maybe like wearing a hoodie in a dark room and launching attacks like malware or ransomware, right? This this can come from things from inside the company, things like technology failures or natural disasters or even the organization's own employees, which we would call an insider threat. And while a vulnerability exposes the organization to threats, the threat actually takes advantage of a vulnerability, which leads us into risk. And risk is the potential for loss or harm or damage resulting from the exploitation of vulnerabilities by threats. It really does, as you can see in the diagram, represent the intersection of vulnerabilities and threats and the assets or resources that they target because a risk is realized when a threat exploits or harms a vulnerability. And often times, organizations and security teams will perform risk assessments that evaluate the likelihood and impact of potential security incidents. And we consider things like the threat likelihood, how probable is it for a threat to exploit a specific vulnerability as well as the impact severity, right? So what is the magnitude or the consequence from this resulting action? As well as the asset value. So what kind of data is at risk? What kind of systems and infrastructure? How critical is it? And we're going to talk more about risk in a bit. But let's move on to some more tangible concepts that as a sock analyst you'll be dealing with on a day-to-day basis. So let's start simple. Let's talk about a log. And we can think of logs as a chronological record of events, actions, or any transaction that occurs within a system. At a high level, a log is going to provide us as analysts and auditors with detailed accounts of any activities or changes or interactions as they relate to a system or the interconnection of systems. There are countless log sources out there and many that we're going to cover. So, this isn't an exhaustive list by any means, but we can start thinking about things like system logs or application logs or maybe network logs that you know document network traffic or connections. So, let's take a look at an example log from a web servers log file. The following log you're seeing here has been extracted from an Apache web servers access log file. So we can actually break this down section by section. Right? We have the IP address here at the start. This is the public IP address of the system that made the request to the web server. We also have a timestamp here. Right? We get the date and the time of the request. Next, this string is going to be the request line. So we can actually break this down further into the HTTP method or the get request. We can see the requested URL that /admin.php. PHP as well as the protocol version, the 1.1. And next, we get the status code. So in this case, it's a 200, meaning that everything was okay. But if we were to get something like a 404 not found, or maybe like a 301 redirect, this would give us more information in terms of how the web server handled this request. And lastly, here we have this weird string. This is a user agent string and it can actually tell us many things about the request or the source of the request including the browser that the requesttor used as well as the operating system used for the request. So we can actually take this IP address that we discovered and perform a lookup to identify where the request came from geographically and what service provider the IP address belongs to. This of course can be useful information during an incident response investigation and it can help us trace the origin of any suspicious activity. And like with the IP address, we can take that user agent string and actually parse it using tools to determine a lot of information that we talked about. So we can extract some valuable information about the user who made this request such as the browser they used, the name and its version, the operating system they're running on, as well as the device type. Is it a desktop, mobile, tablet, and many other additional details. So let's talk about a security event. So a security event is any occurrence that has the potential to impact the security of an organization's informationational assets or infrastructure. And security events can be defined as a wide range of activities, right? So we can think of things like failed login attempts or high volumes of network traffic or a user attempting to run an unauthorized program on their workstation. These may not always turn into an incident, but they should still be investigated nonetheless, right? All incidents are events, but not all events become incidents, which brings us to a security incident. So an incident is a confirmed or suspected breach of any kind of violation of our security policies or procedures or controls that we have in place. And ultimately this poses a threat to our confidentiality, integrity or availability of our organization's assets. So again, all security incidents are events because they involve some sort of observable occurrence. However, not all security events escalate to security incidents. And next we have an alert. And an alert is a notification or a warning generated by a security monitoring system or our tools that indicate a detection of a potential security incident. And alerts are typically triggered based on predefined rules or thresholds or even patterns that we set up to indicate potential malicious activity. Security alerts will often include important metadata, things like the event details or the alert context. Alerts are also typically categorized based on their nature and severity, right? Are they a high or critical alert and require immediate attention or are they more low priority and still require attention but do not pose an immediate threat to the organization? For example, let's take a look at a snort alert that was logged to our SIM. Snort, which we'll cover later on in the course, is a powerful open- source network intrusion detection system. And when we look at the alert here, we can see like with our log example from earlier, some information that we can extract, right? So, we have the date or the timestamp. This is the date that the alert was triggered. We have the priority in this case one which may indicate a high alert severity. We have the protocol which is UDP. The class or the classification gives us some more context and detail into what the alert entails. And we have the source IP address from which the suspicious network traffic originated from as well as the port and the destination port and IP as well. We also get some more information with the SID or the signature ID which is a unique identifier for this rule that we can then look up to get more information. We then have the description here which provides a of course description of the alert indicating in this case that store detected an inbound connection related to the zero access Trojan. So next let's talk about security controls themselves and what types of controls we can decide to implement within our organization. When we start to implement security controls that complement and support each other, we aim to achieve the concept of defense in depth. And this is a strategy that involves deploying multiple layers of security controls and access controls within our organization to protect against a wide range of security threats and vulnerabilities. And this is a strategy that involves deploying multiple layers of security to protect against a wide range of threats. So rather than relying on a single point of failure or a single security measure, defense and depth will emphasize redundancy and diversity and depth within our security defenses to create a more overlapping protection layer. And we can think of the Swiss cheese analogy in which we stack multiple layers of Swiss cheese slices on top of each other. And if you think about a Swiss cheese slice, it's going to have individual holes or weaknesses that threats can exploit. But when we start to stack layers on top of each other, over time we end up patching all of these holes holistically. And when it comes to controls themselves, typically you'll see them separated into three distinct categories. However, we're going to see shortly that this can get confusing and kind of arbitrary. So first let's talk about administrative controls and these relate to the policies and procedures and guidelines that we implement within an organization to manage and mitigate security risks. So for example, we might have incident response plans or security policies. We might provide things like security awareness training. We might implement access control policies and we also have technical controls and these are also referred to as logical controls as well. And as the name suggests, these controls rely on technology to enforce security policies and also do things like detect and prevent unauthorized access. So we can think of things like firewalls, our endpoint detection and response platforms, intrusion detection systems, or even things like introducing encryption, access controls, antivirus software, the list goes on and on. And lastly, here we have physical controls. These are tangible measures that we can implement to protect physical assets or our facility and resources from unauthorized access or even theft or damage. These controls encompass security measures designed to secure the physical environment in which the IT and security systems and infrastructure operates. So we can think of things like surveillance cameras and biometrics or perimeter fencing access control systems, right? Or even hiring security guards. These are all examples of physical controls. Now we can also talk about security control functions and these relate to an actual controls well function or goal or objective. And so to start we have preventive controls and these are security measures deployed to proactively prevent security threats and incidents from occurring. So for example we can implement things like firewalls or access control lists or EDR tools or intrusion prevention systems. And we also have detective controls. So these are measures implemented to identify and detect attempted security incidents. And these focus of course on monitoring and analyzing. So obviously in this case we have our IDS systems or our SIM different log monitoring and analysis tools and things like audit trails as well. And next we have corrective controls and these are security measures implemented to remediate and mitigate the impact of security incidents after they've been detected. So these controls focus on restoring systems or data or operations to a secure state and prevent similar incidents from occurring in the future. So we can think of things like having secure backups or incident response plans or having a patch management system in place which brings us to deterrent controls and these are used to well deter threats from exploiting vulnerabilities. So we can think of things like placing warning signs or physical barriers or tamper seals to prevent tampering. And lastly, we have compensating controls. And these are alternative security measures that we can implement to mitigate risks when a primary security control is either impractical or ineffective or just plain unavailable. And these controls serve as substitutes or even enhancements to primary controls that achieve the same or similar level of security. And often when we're evaluating compensating controls, we need to have a process to accept and document carefully for auditing and compliance purposes. So we can think about using network segmentation as a means to secure sensitive and legacy endpoints from the rest of the network. Right? If we have a very old system that we cannot patch, we physically cannot patch it. Well, we need to have compensating controls in place. Maybe we airgap the system because it can't feasibly be updated. You might have noticed that certain controls can fit into multiple categories. For example, we have surveillance cameras, right? Is it a physical control? Well, I mean, yes, it relates to physical equipment, but when we think about functionality, surveillance cameras can fit as a detective control, right? because we're able to use them to monitor and detect for attempted security violations. But they can also be classified as a deterrent control as the mere presence of having them can discourage physical intrusion attempts. So it's entirely possible that a single security control can fulfill multiple functions. So let's quickly talk about risk again. So SOCK teams employ a range of strategies to manage risks effectively and these strategies encompass various approaches. So we have things like transference or risk acceptance or avoidance and mitigation. Each strategy that we're going to talk about offers distinct advantages and is applied based on the organization's risk appetite or resource availability as well as business objectives. So first we have risk transference and this involves actually shifting a financial burden or responsibility of managing a risk to another party typically through some sort of contractual agreement or policy. So instead of directly dealing with the risk, an organization can just transfer it to a third party that is better equipped to handle or absorb it. So a common example that you'll see is purchasing cyber security insurance. By paying a premium, we can transfer some of the financial risk of the potential security breach over to an insurance company. We can also think of things like moving services to the cloud, right? When we move things to the cloud, cloud service providers actually abstract a lot of the physical and some logical controls away from us. So by paying a premium to shift things to the cloud, we gain a lot in security as well as many other things that cloud providers offer. We also have risk acceptance and in this case it involves acknowledging and continuously deciding to tolerate or live with a certain level of risk without actually taking any actions to mitigate or transfer it. So this strategy is appropriate when the cost or the effort required to reduce a risk kind of outweighs the potential impact of the risk itself. So for example, in some cases, organizations might choose to accept certain operational risks. They might accept a minor service disruption during routine maintenance rather than implementing some costly redundancy measure to eliminate downtime altogether. Right? That's not the best example, but it's often this balance of resources and time and cost as well as the impact. We also have risk avoidance. So this involves taking deliberate actions to eliminate or avoid specific risks altogether. So with this strategy, we aim to completely remove the possibility of encountering a specific risk, thereby preventing any potential negative consequences. For example, an organization might decide that the risk of data breaches associated with storing sensitive customer data is too high. You know, maybe for a simple e-commerce site, an organization doesn't need to be storing financial data for longer than necessary just to complete a transaction. So they put controls in place to only keep that data ephemerally. And lastly, here we have risk mitigation. And this involves implementing proactive measures to reduce the likelihood or impact of any identified risk. So for example, we can implement things like a strong patch management system or plan to mitigate the threat or the risk of thread actors exploiting vulnerabilities or maybe a strong redundancy plan to mitigate data loss and system failure which would of course impact availability. Okay, we're almost done. Let's quickly talk about security policies along with a non-exhaustive list of some common policies that you might see. So security policies are documents that outline an organization's guidance, principles, and procedures for protecting its assets. So these policies typically serve as some sort of framework that establish and enforce security standards or define acceptable behavior as well as ensure compliance with legal and regulatory requirements. So we use security policies to provide that clear direction to employees and contractors and stakeholders within the company on what their responsibilities are for safeguarding the company's assets. So for example, we have acceptable use policies and these define acceptable behaviors and practices regarding the use of an organization's IT systems. So basically what is and what isn't allowed within the organization. And additionally, sometimes you might see this through a separate policy called bring your own device policies. But there are policies that can address the use of personal devices as well and establish rules and security measures for accessing the company resources from personal devices. Next, we have the password policy, which you're likely familiar with as these establish the requirements and best practices for creating, managing, and securing your passwords within the organization. So, it includes things like guidelines for the complexity and length and expiration or even reuse of passwords. Next, we have data classification policies and these categorize information assets based on their sensitivity, their criticality or confidentiality requirements. So it will define classification levels like public or internal or confidential restricted and specify specific security controls and protections that are required for each of these classification levels. We also have change management policies. So these outline the procedures and protocols for implementing, reviewing and approving any changes to IT systems or applications. It defines the roles and responsibilities and establishes a change control process to mandate documentation as well as testing requirements to minimize any disruptions or errors or any vulnerabilities that might be introduced because of these changes. So for example, in an ideal world, we should have a process to document a record of every asset's initial state along with every record of change like an upgrade or an installation or replacement because of course change can bring in new risks to the organization and the grand purpose of any change management process is to minimize that risk. And lastly here we have a disaster recovery policy and these establish the strategies and overall objectives and procedures for recovering any IT system or data or operations and infrastructure in the event of a disruptive incident or disaster. And so it's going to outline the roles and responsibilities of key personnel. It's going to identify critical systems and resources and define things like recovery time objectives and recovery point objectives to adhere to. And through all this, a disaster recovery policy is going to help the organization ensure business continuity, minimize downtime, and also mitigate the impact of unforeseen events on organizational operations. So, we've covered a lot so far, but the one thing we haven't talked in detail about yet is the actual organizational structure of a sock. You know, what different types of roles exist? What does the hierarchy look like? And although security analysts themselves are the backbone of the sock, there are a lot more potential avenues and roles that we can explore that all work together to provide that strong security operations coverage. So first, you'll typically see three different models or arrangements of a sock. There might be many more that you come across, but in general, we can break it down to the following. First, we have an internal sock. And this is going to be a sock that is owned and fully operated by the organization that it serves. So, it's going to be staffed with the own company's security analysts or engineers or incident responders, and the sock is going to be fully integrated within the organization's existing IT infrastructure, and it's going to operate as that typical central hub that we come to think of. Internal socks are great because it offers the most visibility that you're ever going to get and the most control over security operations within your company, but it does obviously come with a large upfront cost to invest in those resources and skilled personnel and technology infrastructure and building up the actual sock along with ongoing training as well. So, as an opposite or alternative, we have the managed sock or the MOC. Sometimes it's also known as security operations center as a service or sock as but typically this is going to be a sock type entity that's outsourced to a third party that specializes in cyber security services. So if you end up working in a managed sock, chances are that you're going to be overseeing a large number of clients and a large number of different systems. And managed socks typically deliver that range of 24/7 monitoring and threat detection and incident response and overseeing the SIM sometimes for a large number of clients like we mentioned. And sometimes different organizations will prefer to have a different amount of managed sock involvement, right? So maybe a certain customer will have some in-house capabilities and would just prefer to offload the burden of the initial alert triage to the managed sock. Other times, your team will be expected to provide assistance and lead response activities for a customer that doesn't have that type of thing in house. But unlike an internal sock, one of the challenges that organizations and sock analysts themselves will face working in a managed sock is that it's going to be hard to maintain visibility and control over the network because after all it's managed by the client. And this leads us to the hybrid sock or the third model here which is going to combine the elements of both internal and managed socks to sort of leverage a mix of in-house resources as well as bringing in external expertise as needed. So this will allow companies to retain that control over their core security functions while also allowing for more extended or specialized capabilities like incident response, forensic analysis, malware analysis, and leveraging third parties for that. Now for the more exciting part, we get to talk about the actual roles and titles that make up a sock. And listen, before we dive in, we need to acknowledge that there's kind of a caveat here. Job titles and roles specifically in our industry are often dynamic and might not always align seamlessly to match what your specific requirements are. And also these roles can vary very significantly between organizations based on again their structure, their size, their maturity and budget. And I'll also mention that we're going to be talking about a tiered model of sock analysts here. And it's important to recognize that a lot of organizations kind of ditch that traditional tiered model and opt for a more collaborative approach. And there's definitely an argument to be made there that a non-tiered setup can kind of promote a more crossunctional team. But I'm not going to get into the debate here. So to keep everything broad and sort of to the book, we're going to essentially cover everything we can. So let's first start with of course sock analysts and these are the frontline defenders in a sock. They're responsible for monitoring and detecting and analyzing and responding to security incidents and threats. So, first we have a typical tier one sock analyst. And these are typically entry-level positions that are tasked with the initial triage and investigation of alerts and incidents. So, they're the ones that are doing that routine monitoring of the systems and analyzing log events and alerts and escalating confirmed incidents to higher tiers as needed. Essentially, their goal is to categorize and prioritize alerts and escalate incidents to the tier 2 analysts as needed. Which leads us to the tier 2 analysts. And in many organizations, you might see the role of a tier 2 analyst be described as an incident responder, especially in a sock team that does not have a dedicated incident response team. So these are going to be more senior analysts, and they're going to be the ones tasked with investigating and remediating escalated incidents. And lastly, here in our tiered model, we have the tier three, which is typically the highest tier that you're going to see. And I will speak generally here and say that a tier three analyst is often referred to as a more proactive role in organizations. and they're sometimes actually treated as threat hunters. So these are going to be the most senior level analysts and they're able to assist the tier 2s with any complex incidents or anything that gets escalated to them. But they will have a primary focus on proactively searching for suspicious behavior or ingesting threat intelligence and performing threat hunting activities and assessments to detect advanced threats and areas of improvement to better their detection engineering efforts. And I've seen different cases of how this is structured. So you might have a setup where a tier three analyst is doing typical instant response and triage during the majority of the week and maybe they have specific days or specific parts of the week where they specifically focus on threat hunting. Again, this is all dependent on the organization and the management of the sock. And lastly here we have a sock team lead. And this isn't always the case. If your team is large enough, you might have a dedicated sock team lead who is the one who's responsible for overseeing the day-to-day operations of all the analysts and managing things like workload and providing guidance and mentorship. But sometimes the responsibility of this lead is served by a tier 2 or three analyst. So in addition to the sock analyst, we sometimes have specialized roles that address specific cyber security challenges and enhance the overall socks capabilities. If your organization is large enough and they invest enough in the sock, you might see one or several of these roles that you might want to actually work towards as you progress your career. So the first one being an incident responder. So this would be where you have a dedicated team that is responsible for responding to and containing security incidents. So they're going to be the ones that are actually leading the incident response efforts and assessing the severity and the scope and executing incident response plans and dealing with you know the collaboration between stakeholders and management and IT and legal and all the other departments that are involved in an incident. So next we have threat hunters. And these again are going to be that proactive role that searches for signs of advanced threats and tries to find hidden security risks within the organization that isn't being detected. So they might be the ones that are developing custom alert and detection rules. They might be ingesting threat intelligence and using that to conduct threat hunts where they try to find known indicators of compromise within their environment. And this kind of leads us to threat intelligence analysts, which are the ones who are going to be gathering and analyzing and disseminating the actionable intelligence on emerging cyber threats or adversary tactics, techniques, and procedures or TTPs related to their organization's threat model. And they'll do this by collecting and analyzing threat data from various sources. So the organization might subscribe to proprietary feeds and actually pay for that threat intelligence related to their organization. or they might use things like open source intelligence or OSENT or things like collaborations with information sharing communities. So typically they're going to be the ones producing intelligence reports. They're going to be reporting on indicators of compromise and developing actionable insights that can help things like the threat hunters or the tier 3 analysts and support things like making the organization more efficient with detecting threats. Next, we have a very important role, the security engineer, sometimes referred to as a security architect. And these are going to be the people who design, implement, and maintain the different security controls, technologies, and the overall architecture that the sock is built upon. So, they're going to be the ones getting that hands-on deployment and design and configuration to actively tune security infrastructure like firewalls or IDs and IPS systems. They might also be the ones conducting security assessments or audits and maybe reviews to identify weaknesses and recommend remediation measures to enhance the security posture amongst the organization. Which kind of leads us into vulnerability management. And if you're in this type of role, you're typically going to be the one who's overseeing the identification, the assessment, prioritization, and also the remediation of security vulnerabilities within the organization's environment. So, they might be the ones conducting vulnerability assessments or scans or coordinating penetration tests to identify weaknesses in systems or applications or any kind of infrastructure within the org. They're going to be the ones going through the reports and prioritizing vulnerabilities based on their risk factors, how exploitable they are, the potential impact and you know relevance to the company. And with this analysis, they'll be collaborating with the IT teams and development teams to sort of implement patching strategies and remediation plans. Next year, we have forensic analysts. And these folks specialize in digital forensics and incident response or what we refer to as defer. So they're going to be the ones collecting and preserving and analyzing digital evidence to come up with timelines and reconstruct events and trace an attacker's activities to support legal and sometimes regulatory investigations. So sometimes this type of function is left to third party companies that come in during or after an incident or sometimes companies engage forensic analysts on retainers for this purpose. So again, these are the ones that are going to be doing the data acquisition to acquire evidence or performing memory dumps or documenting their findings, preparing forensic reports, and maintaining chain of custody. They might need to testify as the expert witness in legal proceedings depending on how severe the incident is. And lastly, here we have a malware analyst. And again, this is one of those specialized roles, which you may or may not see in your day-to-day, but they're going to be the ones that are specialized in analyzing and reverse engineering malware to understand its functionality, behavior, and impact on the systems. Personally, I've never seen a dedicated malware analyst at any of the sock roles I've been in. You're primarily going to be looking at like larger companies or companies that do a lot of research and development. We can think of things like EDR or anti virus companies where having this function would actively benefit the end product of the business. So lastly, let's talk about management type roles. And obviously management roles are going to provide that strategic leadership and direction and overall oversight for all of the sock operations. So first we have the sock manager. And the sock manager is going to be the one who oversees the day-to-day operations within the security operations center. So they're going to be the ones managing the personnel, the resources, the budget, different activities and priorities within the sock to ensure that the monitoring, detection, and response efforts are going as well as they possibly can. And sometimes you might have another role like a director of security. Not all the time, but this is typically going to be a senior leadership role that's responsible for defining and executing the organization's overall cyber security initiatives. So they're going to be the ones providing strategic direction and governance and general oversight for all aspects of security within the company and this includes sock operations. So they might be the ones implementing the standards and policies and controls that protect the organization and support the business objectives. They might be the ones collaborating with executive leadership or board members or external stakeholders to assess risk and prioritize investments. Which leads us into the sea level here with the CISO or the chief information security officer. And this is going to be the highest ranking executive that's responsible for the organization's overall security program and all of these security initiatives. So many of the things we just mentioned for the director often apply to the CISO. So again, they're going to be on that senior management level and on the board to advocate for investments within the cyber security capabilities within the organization. As we dive deeper into this course, we're going to be getting hands-on with incident and event management operations. Because of this, we should understand what goes into incident and event management and make some key distinctions that an analyst must make every day when dealing with handling alerts. So, when we think about event management, we're thinking about the process of monitoring, analyzing, and prioritizing security events generated by our various systems. The goal of event management is to continually collect an accurate record of all the happenings going on across our environment, which gives us a strong visibility into our infrastructure. So as an analyst, we can turn this visibility into actionable insights and allow the sock to identify potential security incidents or anomalies or threats in real time so we can then take the appropriate actions to mitigate those risks. So a crucial first step in being able to manage events is to collect events obviously and we do that by first taking an asset inventory of all the systems and devices within our network to identify where the gaps are and determine what we need to collect. So, these sources of these events include things like firewalls and intrusion detection systems or antivirus software, log files, network devices, user endpoints and hosts, and you know, the list goes on. These events might include system alerts or network traffic logs or authentication logs and application logs. We're going to get more into this in the SIM section, but typically we'll deploy something like an agent or a forwarder to these devices that can then collect and transmit logs. In the cases where we're dealing with like networking equipment or a router or something where we can't actually deploy an agent, we're going to use some other protocol specific means like SIS log or something to then collect that information. So the collected events are then normalized to a common format or a schema that can facilitate consistent analysis as well as correlation across different data sources and technologies. So when we think about normalization, that's going to involve like standardizing the event attributes or the timestamps or even the data formats themselves to ensure that they are consistent across the board. So for example, imagine if we have two different log sources, maybe like a firewall as well as a reverse proxy server that we're collecting logs from. And these two different devices have different naming conventions when they log a source IP address. For example, maybe the firewall logs it as IP source and maybe the proxy server says source IP address. These are not accurate examples, but just so you can start thinking about it. So normalization is going to be the process of parsing the schema of these logs and ensuring consistency when the logs are aggregated. So when an analyst is searching for a source IP address, they're effectively querying a single data point rather than multiple. And so when events meet a predefined rule criteria or different thresholds, they're converted into actionable alerts and are then forwarded to the sock for further investigation and response. As we talked about previously, alerts are categorized in different ways. based on their severity, their urgency, and relevance to the organization itself. And this magical SIM solution that we've been talking about is the centralized platform that aggregates, normalizes, correlates, and analyzes these events. And there are a number of different SIM platforms and vendors out there that provide SIM capability. And you can see some of the ones listed below. On the right hand side we have a screenshot of the Splunk cloud instance but we also have different options like log RHM or IBM's Q radar elastic security grey log or solar winds. So when we talk about incident management on the other hand well this is the process of detecting and responding to and resolving security incidents in a timely and effective manner so that we can minimize their impact. Like with event management, we're going to get deeper into this later on but at a high level the incident management life cycle attempts to follow some sort of a defined process. So we have incident identification. This is when security incidents are identified through our event management process or through our different detection mechanisms or alerts or user reports or external notifications. So there are many different ways and there are many different types of incidents too, right? We might have unauthorized access or malware infections or data breaches or denial of service attacks. You know the list goes on. We then have incident classification and this is where incidents are classified based on their severity, impact and the nature of the threat. And some common classification categories that you might see are like critical, high, medium, or even low severity alerts. And these are going to help prioritize the incident response efforts and allocate resources accordingly. Next, we have incident investigation. So this is where the actual sock analysts are going to conduct their thorough investigations and gather evidence and analyze the root cause and determine the scope and extent of the incident. So they might be looking at logs and doing some correlation and searches or they might be actually gathering forensic evidence on an infected workstation. Next we have the incident containment. So once the nature and the scope of the incident are understood, this is when the sock analyst is going to implement the containment measures to prevent further escalation or minimize the spread of damage. So this might involve isolating the affected systems or blocking the network traffic or disabling compromised user accounts. Next here we have incident eradication which is kind of similar here. This is where after the containment measures are in place, the sock analyst is going to work on eradicating the root cause of the incident and restore the affected system to a secure known good state. So this might involve actually removing the malware or patching vulnerabilities or most likely just restoring data from backups. And lastly here we have incident recovery. So once the incident is resolved, the sock analyst is going to focus on restoring normal business operations and miticate any residual impact. This might include things like post incident reviews and meeting with stakeholders to determine what was the root cause or updating security policies and procedures or providing user awareness training to prevent similar incidents in the future. So let's talk about detection outcomes. So there's some terminology that's commonly used in the context of security event analysis as well as incident response to describe the accuracy and reliability of our detection and alerting mechanisms. And as a sock analyst, you're going to be constantly classifying alerts you receive as true or false positives. And the sock itself is going to be actively tuning its detection capabilities to mitigate any potential for false negatives or missed incidents. So the first one we have here is the false positive. And this is going to be when a security tool or system incorrectly identifies a normal or benign activity as a security threat or an incident. So, for example, we could think of an antivirus program mistakenly flagging a legitimate word processing software as malware leading to a false positive alert. Or maybe a rule is tuned too sensitively and when a user mistypes their password a couple times, the system alerts on a brute force attempt. Next, we have a true positive. So, a true positive occurs when a security tool or system correctly identifies a genuine security threat or an incident. So for example, we could think of a network intrusion detection system or an IDS accurately detects an alert sock analyst on a malicious attempt to exploit a vulnerability on a web server for example. Next we have a false negative and this occurs when a security tool or a system fails to detect a genuine security threat or incident. And these are very scary. So for example, imagine there's a threat actor that evaded a web application firewall and gain access to a web server through remote code execution and then maybe the attacker is able to exfiltrate data or privilege escalate or move laterally without being detected by any network or system rules. Obviously this is very scary. And lastly here we have a true negative. So this occurs when a security tool or a system correctly determines that no security threat or incident is present and as a result no alert is generated. So, for example, we could think of a firewall correctly identifying and allowing legitimate traffic to pass through it without triggering any false alarms or false positives. Now that we have a better idea of what aspects make up a sock, let's quickly look at some of the metrics and benchmarks that are typically used to evaluate the effectiveness and performance of the people, processes, and technology within the sock. This is an important point to cover because as an analyst, you will be the first line of defense and one of the most crucial contributors that actively impacts these metrics on the day-to-day basis. And the reason why metrics are so important to businesses, particularly sock managers and CISOs, is their role in providing quantifiable insights into the socks operational efficiency, effectiveness, and also alignment with the organization's goals. So by collecting these metrics, it enables these stakeholders to assess the sock's performance, identify any areas of improvement, and make datadriven decisions that optimize the security posture of the organization. And while there are a number of different metrics and strategies for measuring performance, you're likely going to encounter some of the following in your roles as they're quite common in the field. I will say though, there are some arguments to be made in terms of weighing and prioritizing certain metrics over others based on organizational priorities and risk appetite. This is not an exhaustive list but rather a starting point for evaluating sock effectiveness and performance. So the first one we have here is the meanantime to detect and this is the average time it takes for the sock to detect an incident from the moment it occurs. And so a lower meanantime to detect indicates a faster detection and response capability. Similarly we have the meanantime to resolution. So this is the average time it takes for the sock to resolve an incident from the moment it's detected. So of course a lower meanantime to resolution indicates a more efficient incident response process and more timely mitigation of incidents. And you know consider a scenario where the sock identifies an incident where an employee fell victim to a fishing campaign. And so after triage and investigation and containment activities as well as recovery objectives, the incident is fully declared resolved within 4 hours. In this case, the MTR or the meanantime to resolution would be 4 hours. And next we have the meanantime to attend and analyze. That one's kind of a mouthful. Um this is the average time it takes for the sock or the analyst to pick up and work on an alert from the moment it's triggered. And so a lower MTA indicates a prompter response and reduce latency in incident handling. So as another example, suppose like a data loss prevention alert came up indicating that there's a potential data exfiltration going on within the organization. So let's say an analyst logs in and picks up the alert within 5 minutes and then conducts their initial analysis and begins fully investigating the incident within 15 minutes. In this case, the MTNA for this alert would be 15 minutes. So next we have the incident detection rate and this is the rate at which the sock detects security incidents within a specific time period. So a higher detection rate indicates better visibility and effectiveness of monitoring the detection capabilities which enables the organization to proactively identify threats and initiate responses. So let's say in a given month the sock detects 90 security incidents out of a total of 100. Therefore the incident detection rate for that month would be 90%. And you might be thinking that of course sometimes this can be a hard metric to track accurately and if you have eventually identified an incident that wasn't initially detected or we had a false negative scenario that's usually a bad day for the sock as the incident has had much more time to propagate. And next we have false positive rates or FPRs and this is the percentage of alerts or incidents that are incorrectly identified as true positives. And so a lower false positive rate indicates more accurate alerting which would result in reduced analyst workload and minimize things like alert fatigue or wasted resources and time spent on false alarms. So let's say the sock receives 200 alerts in one week out of which maybe 20 alerts are later deemed to be false positives upon investigation. Therefore the false positive rate for the week would be 10%. Next we have false negative rates or FNRs. And this is the percentage of true incidents that initially go undetected or missed by the sock. In which case, a lower false negative rate indicates fewer missed detections and fewer gaps in our detection capabilities. And again, you can imagine this is a hard rate to detect unless in retrospect. So in addition to these specific sock metrics, there are also more general terminology and frameworks that relate to performance measurement and management within the sock. So we have KPIs or key performance indicators and these are more quantifiable metrics used to evaluate the effectiveness and performance of specific processes, activities or functions within the sock. So you know all the metrics that we described on the lefth hand side here can all relate and be applied to various KPIs within the sock. We also have key risk indicators or KIS and again these are quantifiable metrics that we can use to assess and monitor the potential risks and threats to our organization's security posture. And so a key risk indicator is typically a measurement that management would use to indicate how risky an activity is. And organizations use these metrics proactively to provide an early signal in increasing risk exposures in various areas of the enterprise. So there's typically going to be some sort of threshold or trigger based on the likelihood and impact of the risk that categorize and define risk factors so they can be documented and risk analysis can be performed more efficiently. And lastly here we have service level agreements. And we've touched on this a bit before. These are agreements between the sock and its stakeholders. So if we're thinking in the example of an internal sock, this would be between the sock and the socks management or the uh organization as a whole. Or if we're thinking of more of a managed service provider, this would be an agreement between the sock and the customers of the sock. And these agreements define the level of service performance expectations and response times most critically for security operations and incident response activities. And so they help ensure accountability, transparency, and alignment with business objectives. So for example, an SLA may indicate that the sock must acknowledge and begin investigating a critical security alert within 15 minutes of its generation. And so you can sort of see how metrics like the meantime to resolution are typically mapped closely with SLAs's to identify gaps in areas for improvement. When thinking about the main pillars that make up a sock, we've identified people, processes, and technology. In this lesson, let's focus specifically on technology and discuss the types of tools that socks use to actually conduct operations at a hands-on level. And while we're going to cover multiple specific tools throughout the course, the highle emphasis that I'm always going to put within this course is that we want to understand the methodologies and processes. Right? So, it's crucial to recognize that tools are just tools. You know, they evolve, they come and go, and while they have similarities between each other, they also have differences. So our goal isn't to become experts in any single tool immediately, but rather to grasp what they do, why they're used, and other methodologies around using them effectively within security operations. And you can see that there are quite a number of different types of tools that socks use. You may or may not use some of these in the field or all of these. It's entirely dependent on your role and the size of the company and the actual capabilities of your sock. But for the sake of being thorough, let's quickly go through each of these at a high level. So first we have the security information and event management system or the SIMS. And a security information and event management system is one of the most important components in modern cyber security infrastructure. So much so that it's often referred to as the heartbeat or the nerve of the sock. SIMs serve as a centralized platform for collecting, correlating, analyzing, and managing security event data in real time. So at its core, a SIM system aggregates logs generated throughout all of our technology within the organization. And then we can employ advanced analytics and correlation techniques to identify patterns or trends or anomalies within the collected data. And by correlating events from various sources using a SIM, we can differentiate normal activity from potentially malicious behavior, which can help us on the security side detect and respond to incidents as they occur. And with a SIM, we can integrate functions like log management, right? So collecting and storing and normalizing log data from all these different sources, but also real-time monitoring. So we can analyze the incoming data streams and in real time identify security incidents as they occur and get alerted on them. Which brings us of course to alerting and notification. So we can actually generate alerts within our SIM. We can set up rules and thresholds to fire off notifications for suspicious activities or policy violations which allow us to rapidly respond. Which of course brings us to incident response. And we also typically have dashboards and reports and visualization capabilities. So we can actually generate reports to share amongst the team or with senior management. We can do things like set up visualizations and statistics to support ongoing monitoring and compliance efforts. And lastly, we can do things like threat intelligence integration. So we can actually incorporate external threat feeds to enhance our detection capabilities. So let's quickly talk about the security orchestration automation and response platform or the soar platform. And this is more of a holistic solution and kind of like a sim on steroids that can combine the power in orchestration and automation with intelligent rapid response. And not all socks are going to have a source solution built out, but it can save a lot of analyst and administrator time by automating repetitive response tasks. You know, we're never going to entirely automate instant response, but source solutions can certainly alleviate some of the manual work. And we can do that through orchestration, right? So with this orchestration capability, we can seamlessly collaborate and integrate between different security technologies like our SIM, our threat intelligence, and different security controls like our firewalls and ACL's, identity and access management systems. So we can automate some tasks that usually require manual work, which of course leads us to automation, and we can free up security analyst time to focus on more complex and high priority tasks. Sore platforms can even do things like automated artifact collection. For example, if a reported fishing email comes through the platform, it can automatically conduct an initial analysis and extract specific artifacts and indicators like domain names or emails or IP addresses. And through using automated playbooks or runbooks, source can help streamline incident response processes and ensure that we have a consistent and effective response every time. And we can also integrate things like threat intelligence and then generate reports and metrics from our SOAR platforms as well. So next we have incident management tools. And this is kind of like a catch-all kind of term because in general incident management tools are solutions we have that are designed for the detection analysis but more so the resolution of security incidents within the organization's infrastructure. So they provide this centralized platform for us as a team to coordinate our efforts, collaborate, document progress and also manage incidents effectively. So we can start using things like ticketing management systems that allow us as analysts to create, assign and track incidents throughout the entire incident life cycle. And these tickets can serve as a central repository for all the information related to each incident. And we can also link incidents together as needed. We also have alert management. So through these tools, we can integrate with our security monitoring systems like our SIMs or any of our you know detection and prevention solutions to ingest security alerts generated from all these sources. So we can automate things with like workflow automation. So when we get an alert generated, we can automatically create a ticket for that alert and make sure nothing gets missed. And obviously here we have the whole collaboration aspect where we can effectively communicate and collaborate amongst our team which is often very essential during incident response. You can see some examples here. Some of these are more general just IT ticket managing systems like Atlassians Jura or Service Now Freshworks. We also have some specific ones like on page. Next we have network security monitoring or NSM and this specifically focuses on the detection and mitigation of network related threats and vulnerabilities. So these tools provide us with the capacity to monitor network traffic, analyze network behavior and of course identify potential incidents in real time based on different rule matching and anomaly detection and behavior detection. So we can do things like packet capture and analysis. So this allows us to actually capture and analyze network traffic in real time or retrospectively. And these packet captures can give us a detailed insight into the network communications and things like protocols as well as source and destination IPs, the actual content within payloads and many more capabilities. We can also do things like perform network traffic analysis and use techniques like statistical analysis, machine learning and behavioral profiling to identify potential security threats. There's also some overlap here with our intrusion detection systems or our IDS systems. And some network security monitoring tools actually have built-in IDS functionality which allows us to detect and respond to known and unknown security incidents in real time. So we can utilize things like signaturebased detection, anomaly based detection, and protocol analysis to identify an alert on suspicious network behavior. And of course, what would any of this log collection be if we cannot integrate it into a central repository, which of course we can do through integrations with our SIM platform. And this integration enables the correlation of network security events with other security data like log data or endpoint telemetry and threat intelligence feeds. So we can start correlating and get a central security monitoring and incident response solution. And you can see some common examples here. And we're actually going to get hands-on with some of these which I'm very excited for like Snort and Siraata and Wireshark. And there's also things like Zeke and Nagios. So we've talked about IDS and IPS systems quite a bit actually. So let's get into what they actually are. So intrusion detection systems and intrusion prevention systems are designed to monitor network traffic, detect potential security events and take action to mitigate and prevent unauthorized access and malicious activities. So what is the difference? Right? So an IDS system or a detection system is going to passively monitor the network traffic and analyze it for signs of malicious activity. And so they're specifically designed to detect security incidents and generate alerts based on their predefined criteria like known attack signatures or anomalous behavior or different policy violations that we set up. An IPS system on the other hand is used to prevent attacks and it actually builds upon the capabilities of an IDS by actively blocking or preventing detected threats in real time. So in addition to detecting security incidents, IPS systems have the ability to take automated actions and mitigate or stop malicious activities before they can cause harm to the network. And of course, both of these tools are going to have detailed logging information that we can then forward to a SIM or a centralized management tool for more event correlation. And again, we have some similar players here. We have Snort or Siraata or Zeke. This brings us to endpoint detection and response or EDR. And these tools specifically focus on the protection of endpoint devices such as laptops or desktops, servers, and even mobile devices. EDR tools are typically deployed with an agent that sits on the endpoint, which provides our organization with that sort of single pane of glass capacity to detect, investigate, and actually respond to security events as they occur at the endpoint level. So, of course, we have real-time endpoint monitoring. So, an EDR tool or an agent is going to be continuously monitoring the endpoint device for any suspicious activities and behaviors. And behaviors is the main thing here. We can look at things like suspicious processes that are starting up or parent child relationships or unauthorized access attempts or known malicious downloads. By collecting all this telemetry, we can actually provide some real-time visibility into our endpoints. And this brings us into user entity behavior analysis or UEBA. And so our EDR tool is going to leverage behavioral analysis and behavioral capabilities to detect things like insider threats or compromised accounts by monitoring user and entity behavior on all the endpoint devices. So they can look at things like login patterns and user activity, file access behavior, you know, when is a user typically accessing a file or logging into their system and a number of other behavioral indicators to identify potentially anomalous or suspicious activities. We also have more general threat detection and prevention. So we can introduce things like signaturebased detection, machine learning and huristics to identify and prevent even unknown security threats. So of course an EDR tool is going to be almost crucial for us in incident response and incident investigation if we're dealing with an endpoint which we often are. And through that these tools are going to facilitate rapid response and remediation actions to mitigate these threats and contain incidents. We can do things like quarantine and isolate and roll back files for example. We can kill processes and patch management all remotely to respond to incidents as they're occurring. And of course, all of the logs that we generate, all of the alerts from our EDR tools can and should be forwarded to our centralized logging capability or our SIM. And you can see some examples here. Of course, CrowdStrike Falcon, we have Sophos, Carbon Black, Sentinel 1. There are many EDR tools out there. And next up, we have firewalls. And firewalls are a fundamental component of network security designed to monitor and control incoming and outgoing network traffic based on predefined security rules. And in the traditional sense, they kind of act as this barrier between a trusted internal network and an untrusted external network such as the internet. We also have different types of firewalls depending on specific use cases and feature complexity. So we have the most common network firewall that you're probably familiar with. These are also known as just traditional or stateful firewalls and they operate at that network layer or layer 3 of the OSI model. They examine packets of data as they pass through the firewall and make decisions based on factors like the source and destination IPs, the port numbers and protocols. We also have the concept of next generation firewalls or NGFWs and these are more advanced firewall solutions that integrate additional security features beyond the traditional network firewalls capabilities. They combine stateful packet inspection with more advanced security technologies like deep packet inspection where they can actually open up individual packets and inspect them at that level or things like application awareness because again they work on that layer 7 or application protocol. And lastly here we have the web application firewall or the WFT and these are specialized firewalls designed to protect web applications from a variety of web-based attacks like SQL injection, cross-sight scripting and other application layer vulnerabilities. And again, unlike traditional firewalls, these also operate on layer 7 because they're dealing with the application layer. And you can see some common examples here of firewall technologies like Palo Alto, Sonic Wall, PFSense, Juniper, F5, and more. Next, we have threat intelligence platforms. And these are designed to aggregate, analyze, and operationalize threat intelligence data to enhance our defenses and improve threat detection and response capabilities. So these platforms can aggregate threat intelligence data from a wide variety of sources like open source feeds, commercial providers, government agencies, or even specific industry groups. And they can then enrich our raw threat data by correlating and contextualizing it with this additional information like threat actor profiles, malware characteristics, attack techniques, or even indicators of compromise. And IoC's or indicators of compromise might be things like hashes of known malware executables or known malicious domains or IP addresses or different tools that adversaries are using or even like host and network artifacts on systems or even the tactics and techniques themselves that adversaries use during an attack. And we can also think about things like normalization and standardization where this threat intelligence data is consistent and operable across many different sources and formats. And they use specific schemas and protocols, things like sticks and taxi, which we're going to cover later on, which make it easier for security analysts to ingest and consume and analyze this threat intelligence data. And of course, we can integrate all of this within our SIM. So we can actually get that data enrichment right from a single pane of glass. And we have a couple different examples here. We have OpenCTI, we have the MISP threat sharing platform, we have Maltego or Maltiggo, however you want to pronounce it, as well as Recorded Future. Getting close to the end here, we have forensic analysis tools. And these are specialized pieces of software that are designed to collect, analyze, and interpret digital evidence from computer systems or networks or storage devices for the purposes of forensic investigations. And through these tools, we can do things like data acquisition and imaging where we're actually creating forensic images or bit-by-bit copies of storage media so we can preserve the integrity of the original evidence. We can use tools that can perform file system analysis and actually extract metadata or file attributes, timestamps. We also have a suite of tools that can do memory forensics. So, we can actually capture memory dumps from compromised systems. We can analyze that volatile memory or RAM for evidence of malicious activities, things like fileless malware, any modules or DLS that were loaded or even open network connections. We have tools for registry forensics where we can actually uncover evidence of user activity and system configuration changes to find things like malware persistence mechanisms or even network traffic forensics where we can look at things like network traffic logs or packet captures which again there's some overlap here with some of these tools and we're going to be covering some of these tools in the digital forensics section like autopsy and volatility. We also have the Eric Zimmerman tool suite and things like cape and INC case as well. And lastly here we have malware analysis tools and these are specialized pieces of software that are designed to analyze and dissect malware to understand its behavior functionality as well as the impact on systems and networks. And it's also useful sometimes to know what types of threats and how advanced threat actors are who are targeting our organization. So we can do things like dynamic analysis where we can actually execute and detonate malware samples in a controlled environment like a virtual machine or a sandbox so we can then monitor the behavior in real time. You know you can think about investigating a potential fishing email that contains a word document attachment. You want to perform some dynamic sandbox analysis to determine if there are any malicious macros embedded inside that execute when it's opened. So we can observe and log the activities like file system modifications, registry changes, network communications or processes that are being spawned. Basically any system interaction that helps us understand the malware behavior. There's also the concept of static analysis where we can actually provide tools with a sample of malware for it to without actually executing it but focus on examining the file attributes and code structure embedded resources and metadata. There's also signature and pattern matching capabilities where we can look at known signatures or patterns or heruristics stored in malware databases and threat intelligence feeds so we can identify known threats and variants. And another way to say this is that we can integrate with our threat intelligence platforms to correlate analysis results with existing threat intelligence data and feeds. And to wrap this up, you can see some examples here. We have a screenshot of any run which is an interactive malware analysis suite. We also have other tools like hybrid analysis, Joe sandbox as well as gedra for actual reverse engineering purposes. Okay, we are finally at the home stretch of this section. So, thank you for sticking this out. Throughout the course, we're going to be covering a number of detection and response efforts for a number of different types of attacks and subsequent incidents. And because of this, it's going to be very important for us to have a good understanding of what the most common attacks and threats are that Sock teams typically face. So, you can see a number of different attacks laid out on the screen here that we're going to cover. And these various attacks can target different vulnerabilities or weaknesses, but ultimately they all have similar objectives or goals in mind to compromise a system or excfiltrate sensitive data. So, let's start out with social engineering. And we've talked about it quite a bit before. Social engineering is an attack that exploits the human side of cyber security rather than any kind of technical vulnerability. And a common goal here is to gain some sort of unauthorized access to a system or exfiltrate some sort of data or gain some sort of user credential that can then be spoofed or impersonated. So for example, we can think of an attacker posing as a trusted IT technician and maybe they call up an employee claiming that there's a problem with their computer or their account and they request their login credentials so they can fix it. and the employee thinking that it's a legitimate IT technician might actually give their credentials over the phone leading to an account compromise. And we've talked about fishing a lot too. And fishing involves sending some sort of deceptive email or a message to someone and appearing to be from some sort of legitimate source like a bank or a trusted organization. And these emails will typically contain an attachment or some sort of malicious link that when clicked that can lead to a malicious website to trick a user into putting in their credentials or downloading some sort of malware. And we're going to cover fishing and analyzing fishing emails in the next section of this course. But at a high level, we have different types of fishing, right? We have spear fishing, which is a targeted form of fishing where an attacker is going to tailor their message specifically to an individual or an organization. So often this requires a lot of research beforehand so an attacker can personalize their email with convincing details or gain some credibility to make them more likely to succeed. We also have whaling, which is a type of spear fishing, which specifically targets high-profile individuals within an organization. So, we can think of people like senior executives or some sort of senior management because these types of people typically have more access or more exposure to sensitive information that can be stolen. We also have fishing or voice fetching, which was in our example. This is where an attacker calls someone over the phone and attempts to trick them into providing sensitive information, performing certain actions, or giving up their account credentials. Similarly, we have SMS fishing or smishing, which is the same kind of thing, but an attack conducted through text messages or SMS messages. So, you may have gotten a suspicious text before from a number you didn't recognize that asks you to click on a link or visit a web page. Most likely, this was a smishing attack. And lastly, here we have quishing, which is a weird word, but essentially refers to QR code fishing. And this is a similar type of attack where an attacker is going to try to deceive someone into scanning a malicious QR code that is then going to lead them to some sort of fishing website. So, let's talk about malware or any malicious software that's designed to harm or exploit an organization or an individual because there's several different types of malware that we can cover here. And the first one here being a worm. And a worm is a malicious program designed to replicate itself and spread across networks or on the internet and often without requiring any user interaction. So they may do this by exploiting some sort of vulnerability so they can infect and propagate throughout a network and infect more people. We have a couple notable examples of worms. So first we have stuckset which was a highly sophisticated worm discovered around 2010 but was in development from much earlier and it was specifically crafted to target SCADA systems used in industrial environments and particularly to attack Iran's nuclear program. And it did this by exploiting multiple zeroday vulnerabilities and chaining those together to infect and propagate. We also have blaster which is the one pictured here on the right. This is a hex output of what the actual worm looked like. And it was an older worm back in around 2003 that exploited a vulnerability in Microsoft Windows. And while technically a ransomware, if you remember Wukry from 2017, it used wormlike capabilities to propagate across the network. Specifically, it exploited a vulnerability in Windows Server message block or the SMB protocol to infect unpatched Windows systems. So, let's quickly talk about spyware and adwear, which are similar but share some distinctions. And these are types of malware that either covertly monitor user activity or display unwanted advertisements respectively. So with spyware, it's specifically designed to again secretly monitor and collect information from a user's computer without their knowledge or consent. And it can do this by things like installing a key logger or tracking keystrokes or capturing screens or the webcam. It can look at browsing habits of the user or gather some sort of other personal information and send that to somewhere else. AdWare on the other hand is often bundled with other software like free applications or browser extensions you find. And again, it's typically installed without the user's explicit consent. But the primary purpose of adwear is to generate revenue by delivering targeted advertisements to the user. So you might install adwear unexpectedly and start to see a bunch of ads on your desktop or within the homepage of your browser or your search bar. So next we have Trojans, which is actually named after the famous Trojan horse from Greek mythology. And they're a type of malware that, as the name suggests, disguises itself as a legitimate program to deceive users into executing it. So unlike worms, which can actually self-replicate and spread on their own, Trojans will typically rely on social engineering tactics to trick users into installing or executing them. They're typically distributed through various channels. So things like fishing email attachments or on malicious websites or within a software download, often masquerading as some sort of legitimate or innocent looking file like a game or some sort of extension or a productivity application. And most commonly Trojans are going to be in the form of remote access Trojans or RATS. And these are a type of Trojan that gives an attacker remote control over a system. And they will typically create a back door on the infected system so the attacker can return and regain that access as desired. And this may lead into some sort of botnet recruitment where a Trojan can be used to recruit infected systems into a botnet which is a network of compromised devices that use a central command and control server. And we'll touch on botnetss in a second. But lastly, Trojans can be used to actually deliver ransomware. And speaking of ransomware, well, ransomware is a very scary type of malware that's designed to encrypt files on a victim's computer or within a network. and it renders these files inaccessible by demanding a ransom payment in exchange for the decryption key. And typically a ransomware attack is going to follow a specific sequence of steps. So first obviously there's going to be an infection and this could be through a malicious email attachment like a fishing email like we said or through a compromised website. Maybe someone accidentally downloads something. It could even be like a Trojan. Maybe someone thinks they're downloading a music app. But in reality it's going to be ransomware. And once the ransomware gains access to the system, it's going to start quickly encrypting files using that strong encryption algorithm and using public key infrastructure so that they can't be decrypted without that specific key. And after encrypting files, you're typically going to see some sort of ransom note like we have on the right here that informs the victim that their files have been encrypted and provides instructions on how to actually pay the ransom back, which is typically going to be done through some sort of cryptocurrency because cryptocurrency is a lot more difficult to trace. And lastly, we're going to have decryption if you're lucky because this is a cyber criminal we're talking about. So even if the ransom is paid by an organization, there's no guarantee that they're going to actually get the decryption key back to recover their files, which is why having strong backups and recent backups is the most important and most useful way to get around ransomware. So we mentioned botnets before, and a botnet is a network of compromised devices or computers that are infected with malware, and they're typically referred to as zombies because they're essentially being controlled remotely by a single entity. And botnets are often used in various malicious purposes like launching and staging denial of service attacks or DDoSes, distributed denial of service attacks or spreading malware or sending spam emails or even things like mining cryptocurrencies without a user's knowledge. We also have fileless malware which is also known as memory based malware. And this is a type of malware that operates primarily within memory and it's able to execute and operate without leaving traces of its presence on the victim's file system. So unlike traditional malware that relies on files and executables to infect systems, fileless malware can leverage legitimate systems or something we refer to as living off the land to carry out malicious activities which makes it a lot more difficult to detect and log. So often fileless malware is going to use techniques like Windows PowerShell scripts or Windows management instrumentation or WI or even inject malicious commands within memory to carry out its objectives. Now, this is a big one. Identity and account compromise. And they're kind of two separate things, but identity and account compromise or also known as identity theft or account takeover occurs when an unauthorized individual gains access to someone's personal information or their user credentials or their online accounts without their permission. And this can include various types of sensitive data like we mentioned like usernames, passwords, even things like social security numbers or credit card numbers. And once an attacker gains access to an individual's account or identity, they can carry out various types of malicious activities like impersonating them or even fraud and making unauthorized purchases using their stolen credit card information. If an attacker can impersonate a victim, they can start sending spam emails or fishing emails from that compromised user to make them appear more legitimate. And often this type of attack can be done through fishing or brute forcing credentials or things like credential stuffing where an attacker gains a user's credentials through a breach and then subsequently tries that password or credentials on different services for that user to try to gain access as well. Next we have insider threats and these refer to the risk that an organization faces by individuals from within that organization or someone who has authorized access to sensitive information. So these may be current or former employees. It could be contractors or partners or any trusted entity that has legitimate access privileges. And insider threats can often manifest in various forms. So we may have a malicious insider and that's someone who intentionally misuses their privileges to steal data or commit fraud or uh sabotage the company in some way. But we also have careless insiders. And this is someone who inadvertently compromises their security through things like their negligence or carelessness or just their general lack of awareness. And lastly, we have a compromise insider which could be the result of something like identity or account compromise. And this is where someone's credentials or access privileges get compromised by an attacker either through fishing or social engineering and then the attacker is then exploiting that account to gain unauthorized access and steal sensitive information. And as you can imagine, insider threats can have serious consequences for organizations and lead to things like data breaches or IP theft or financial loss, reputational damage, and even legal liabilities. The other thing, too, is that insider threats can be very challenging to detect and mitigate because insiders often have legitimate access to these services and can often blend in with normal user behavior. We also have advanced persistent threats or APS and these are sophisticated cyber groups that are highly orchestrated and highly skilled and often wellunded such as nation state actors or organized crime groups. And unlike typical cyber attacks which are more opportunistic and may be short-lived, APS are characterized by several things like their sophistication. So they might employ advanced techniques and tools and develop their own custom malware or leverage zeroday exploits. And as the name suggests, they're often persistent. And these groups are able to maintain long-term access. We're talking like months or years. And they're often very targeted, right? So, not every organization is going to have an AP in their threat model. We're mainly thinking of specific organizations or industries or government entities or even countries. And lastly, they typically have strategic objectives. So, they're trying to do things like espionage or steal intellectual property or sabotage or cause some sort of disruption to critical infrastructure. And many vendors actually categorize APS based on their industry and geography. For example, Crowdstrike uses a naming convention called Falcon Intelligence to identify AP groups, which you can check out at this link here. And you can actually search based on your industry and your business size as well as your country. But if we just start looking at some of the groups here, you can see we have different known groups as well as their names depending on their country, right? So with Iran, we have banished kitten or static kitten. With Russia, it's primarily bears, right? We have fancy bear or cozy bear. We can also view these groups in a different naming convention with mandant. So mandant as you can see uses this apt format with different numbers to attribute different groups. So for example a39 is attributed to Iran and a31 is attributed to China. And we can actually view these groups on the miter attack framework which we're going to look at later in more depth. But just as a quick aside you can see we have this groups tab here where we have all the different names and their IDs. And if we just do a search for fancy bear, you can see we have that under AP28, which is the Mandant naming convention as well as the crowd strike naming convention with fancy bear here. And if we click to a specific group name and scroll down to techniques used, we can actually see what types of common techniques and tactics does this group use. So we can see here with fancy bear or apt28, they typically use a PowerShell command lit to grant the application impersonation role to a compromised account. So we also have denial of service attacks which are aimed to disrupt or degrade the availability of systems and often this could be done by overwhelming them with a flood of traffic or resource requests. And denial of service attacks don't always have to be intentional. For example, some sort of system failure or accidental misconfiguration or just general network congestion or spikes in legitimate traffic can also cause service interruptions. Now we also have distributed denial of service attacks which we mentioned earlier where they have multiple compromised systems or devices to target a single system. By using multiple devices and compromised zombies, an attacker can amplify their attack making it much harder to defend against. However, there are a lot of service providers out there that offer things like DOS protection where they're going to leverage scalable and elastic cloud infrastructure to spin up extra resources in the event of a DOS so that the organization can ride out the storm so to speak. But this can be costly obviously. It's more of an insurance type of thing. So, we have data breaches which are going to occur when sensitive or confidential information is accessed or disclosed or stolen without authorization. And data breaches are often the outcome of some of the threats that we mentioned earlier like cyber attacks or insider threats. But they can also be disclosed accidentally through human error or misconfigurations or just inadequate security controls such as like a non-secured S3 bucket in the cloud. Just as an example or an anecdote, I once led the incident response efforts on an information disclosure incident where that the customer reports that were generated from one of our organizations systems were accidentally being hosted on publicly accessible links. The only reason that this was identified is because these links were being crawled and indexed by search engines which was quite a serious concern and required a lot of recovery efforts and contacting multiple search engines and website archives to ensure that all of this data was wiped. So obviously with data breaches we can think of a lot of reputational damage that can occur or regulatory trouble. And so nearing the end here we have zero days which are software vulnerabilities that are unknown to the software vendor or developer and have not been patched or fixed to date. And these are called zero days because they are typically exploited by actors before the vendor has a chance to release a patch leaving vendors with zero days to fix the vulnerability and users or organizations with zero days to protect themselves. And zero days themselves can often exist in various types of software. So operating systems or web browsers, applications, databases or even firmware themselves. Historically we can think of things like heartbleleed or shell shock or log forj. Typically due to the nature of zero days, organizations are left to rely on risk mitigation and avoidance strategies through implementing things like compensating controls until an official patch from the vendor is released. And lastly here we have supply chain attacks. These are a type of threat or attack that targets the software supply chain to compromise the security downstream to organizations or users. So instead of directly attacking a target organization systems or networks, attackers are going to exploit vulnerabilities or weaknesses in the software or services provided by third parties, vendors or partners. And because of this, the threat is going to propagate down, which makes it hard to detect, right? Because this is a type of malware that's from trusted entities. It might actually be digitally signed as well by trusted entities. So hopefully this gives you a good understanding of the common threats organizations face and gives you a good primer that prepares you for the next section of this course. Welcome to the fishing analysis section of this course. And this is a topic that I really wanted to do justice and give it the true focus that it deserves. Because although we talk about how every sock is different and every organization has different priorities or threat models or attack surfaces, one constant is that no matter any of these variables, chances are that fishing is going to be one of the consistent threats that your company faces. And this is due to its, you know, ubiquity and its low barrier for entry for attackers and quite honestly its success rate. It is often a good return on investment for attackers to employ fishing techniques. And I also thought it would be a good idea to cover this first in the course because although many of the analysis and response concepts that we're going to cover here are going to be built upon later on in the course, analyzing fishing emails is a great practical skill to have in any security analyst role and one that we can readily dive into here. So let's quickly cover our objectives for this domain. First, we want to understand the fundamentals of fishing and its prevalence. We will soon learn why fishing is such a big deal in pretty much any organization that we find ourselves in. Next, we want to learn a strong methodology for analyzing fishing emails. You know, if we want to analyze effectively and efficiently, well, we need to have a strong process that we can rely on. We also want to develop, of course, some hands-on skills, specifically in analyzing the email content or the email headers. And we want to be able to trace the original senders of emails. You know, we're going to take a look at many real life fishing email examples and how to extract malicious artifacts or indicators of compromise and also understand the true nature of these emails. And next, we want to gain an understanding in identifying and analyzing malicious URLs and attachments. So, we're going to look at some manual and automated means to again extract those IoC's and make determinations and judgments. And we want to explore both proactive and also reactive defense strategies against fishing attacks. So, we're going to take a look at how organizations can prevent or most likely mitigate fishing at the source or through technical means. And lastly here, of course, we need to learn to document and communicate our fishing analysis findings correctly and proficiently. You know, there's no point in building all of this methodology and gaining these hands-on skills if we can't communicate it or have another analyst follow our steps. So, we're going to cover how to properly write reports and what we need to include when we close out fishing tickets. So, first here, what exactly is fishing? You know, we covered it briefly before, but at a high level, why is it something that we should be concerned about? And what role do sock analysts play in the day-to-day for defending against fishing attacks? Well, fishing, as we've covered before, can be described as an attempt to steal information from victims through the use of social engineering techniques and various communication channels like email or SMS or even over the phone or on the web. And often this is done with a malicious individual impersonating a legitimate organization or a legitimate entity to trick recipients into revealing that sensitive information. Things like their passwords or their credit card numbers or other sensitive files that the attacker finds useful. And another common goal of fishing attempts is to have the recipient either download a file or visit an infected site so that malware can then be downloaded and installed onto the victim device. And fishing attacks are so prevalent in organizations because they exploit what we would typically refer to as the weakest link in the security chain, the humans. These recipients or end users are often the first line of defense against fishing attempts because they're the ones who are actively receiving them. And it's very easy for attackers to cast a wide net by sending fishing emails to entire companies or departments and hoping that just one of those individuals will take the bait. And once a fishing email is successful, of course, it can lead to severe consequences. things like unauthorized access or account compromise, stealing sensitive data or financial or reputational loss. And of course, this isn't to say that end users are the problem or anything. It just means that that's where we need to focus the most on proactive defense measures. And we'll get to that later on in this section. You know, while we have many technical controls that we can implement to mitigate fishing attacks from getting to our users at the source, well, not everything is foolproof at the end of the day. Remember, we think of this concept of defense in depth. Us as sock analysts need to be quick and efficient at spotting and analyzing and of course responding to fishing emails because we are the frontline defenders against these threats. So how does fishing actually work? And you know fishing or rather social engineering itself exploits several human principles to achieve its objectives. So, we can list some of these out, right? We have authority. And so, fishing emails will often impersonate a figure of authority such as a company executive or a manager or even the IT staff and by claiming to represent a trusted and authoritative source. Well, attackers might be able to compel victims into complying with odd or malicious requests without question. So, for example, a common fishing scenario with organizations is an email supposedly from the CEO requesting employees to buy gift cards for some seemingly legitimate purpose. Because the email is often spoofed as the CEO, this impersonation of a top authoritative figure in the company might actually persuade employees to make these purchases and send the details to the attacker. Another common example is someone seemingly from the IT department claiming to be conducting some sort of audit or security audit and requesting employees to provide their login credentials to verify their accounts. The next one we have here is trust. And fishing emails often rely on elements of building up trust such as using authentic looking logos from trusted organizations or official sounding language or even making references to reputable companies or you know internal company policies. And by crafting this illusion of trust, attackers aim to lead individuals into that false sense of security, which in turn increases the likelihood of compliance with their requests. So for example, an attacker might send out an email appearing to be from a well-known bank. Maybe the attacker actually went as far as to conduct research into the area and identified that a particular bank is very common among these employees. And so a legitimate looking email from this bank requesting some sort of account verification might have a good chance at deceiving recipients into logging into some sort of credential harvesting page or providing their sensitive information. So next we have intimidation. And fishing attacks can use intimidation tactics to instill a sense of fear and attempt to coersse individuals into some sort of immediate action. So we can think of things like threats of legal consequences or account suspensions or financial penalties. These can all sort of intimidate recipients into complying with the attacker's demands. So, for instance, maybe an attacker sends out an email warning of an impending legal action unless an employee sends over information or pays a fake invoice. You know, depending on the wording of this email, an attacker might be able to induce a sense of fear or panic and prompt individuals to act impulsively through intimidation. We also have social proof or this concept of consensus. And fishing emails might leverage the concept of social proof by referencing other individuals or even organizations that have supposedly benefited from taking similar action. And by implying that there's already this widespread sense of acceptance or endorsement, well, an attacker might be able to trick individuals into validating the legitimacy of their request and reduce any chance for skepticism. So, for example, an attacker could send out an email claiming that, well, thousands of satisfied customers have already verified their accounts and now you can, too. or emails like hundreds of investors have already gotten rich by signing up to our investing platform, that kind of thing. Which brings us to urgency. And so fishing emails often, as the name suggest, can create a sense of urgency by emphasizing a time-sensitive issue or impending deadline. And often this can take the form of some sort of urgent request for account verification or a mandatory password reset or a financial transaction that needs to occur. And due to the time-sensitive nature of these requests, well, they can pressure recipients into acting quickly without fully evaluating the legitimacy of the claim. So, for example, an attacker could send out an email warning that there was unauthorized access on their account and they urge for an immediate password change as their account is now at risk. As another example, a common tactic is emails that mention a user must update their password immediately or their account will be locked out indefinitely. We also have the concept of scarcity, which is related but not the exact same as urgency. So unlike urgency which again urges negative consequences for account lockouts or security issues, scarcity is often done by suggesting that an opportunity or resource is limited or time-sensitive. And so attackers aim to provoke a fear of missing out or FOMO and prompt recipients to act quickly. So for instance, an attacker might send out an email offering an exclusive access or limited time discounts or promotions. And due to the human nature of not wanting to miss out on these opportunities, these types of emails might tempt individuals to click on a malicious link or provide information without thinking it through. And lastly, here we have familiarity. And this refers to a sense of recognition or acquaintance with someone or something. And in the context of fishing, attackers can exploit familiarity by creating an illusion of pre-existing connections or interactions to lower a recipient's guard. And so this tactic aims to make the fishing attempt appear more credible and less suspicious by leveraging elements that the recipient finds familiar or recognizable. So for instance, imagine an email that's masquerading as communication from a familiar friend or a colleague or some sort of reputable organization. By playing on the feelings of familiarity, an attacker might be able to evoke a sense of trust and acquaintance, making individuals more susceptible to manipulation. And lastly, here as another example, maybe an attacker is able to compromise an actual victim's email account. And so they might use that newfound access to stage more sophisticated attacks using the concepts of familiarity. And so maybe once they gain access to someone's inbox, they start replying to ongoing threads or emailing known users based on the user's contacts. And so when these future victims receive an email coming from a legitimate contact, well, they'll very likely trust the content of the fishing email and be less inclined to question its authenticity or legitimacy. And so lastly here, I've stressed a couple times now how prevalent fishing attacks are. So let's take a look at some real world examples of actual fishing attacks in the wild and how they compromise organizations through that weak link and the devastating impact that they've had. And quite honestly, when I was compiling a good list of stories to cover here, well, there were actually so many options to choose from, which really speaks to how some of these attacks occur. But I think this is a decent list of notable attacks to start with. So, first we have the Colonial Pipeline attack back in May of 2021. And Colonial Pipeline is a major fuel pipeline operator in the United States. And in back in May of 2021, they fell victim to a sophisticated fishing attack attributed to the Russian-based Dark Side hacking group, which is known to target its victims using ransomware and extortion. And in this case, the attackers used fishing emails to deliver ransomware onto the Colonial Pipelines network. And as it typically does, the ransomware quickly spread and ended up infecting critical systems that actually disrupted the pipelines's operations. And so as a result, Colonial Pipeline was forced to shut down its pipeline, which caused a number of fuel shortages and panic buying across the United States. So much so that nearly half of the US East Coast oil supply was shut down for a week. As for the ransom, the attackers demanded a payment of 4.4 million in Bitcoin to restore the access to the Colonial Pipeline systems. And quite honestly, this incident really highlighted how something as simple as fishing can lead to such devastating economic and societal real world consequences. And the second one here has to do with Levitas Capital back in 2020. And Levitas Capital was a New York-based hedge fund that became the target of a fishing attack. And specifically, it was a whailing attack that was targeted against its co-founder. And as it was reported, an attacker sent out an email containing a malicious URL for a fake Zoom meeting. And back in 2020, well, this was particularly around the time where remote work and Zoom really started taking off, which of course attackers took full advantage of. So this one malicious link led to the download and installation of malware and eventually led to attackers generating over 8.5 million in fraudulent invoices. And as you can expect, this kind of attack led to both financial but also reputational consequences. So much so that the fund ended up losing clients due to its impact which ultimately led to the closure of the business. And so third here we have the ubiquity networks attack back in 2015. And ubiquity is quite a large networking technology company. But back in 2015, well, they fell victim to once again a sophisticated fishing attack. In this case, it was reported that this type of attack was a CEO fraud or a business email compromise attack. So, this type of attack usually begins with an attacker either fishing an executive and actually gaining access to their inbox or emailing employees from a spoofed lookalike domain that looks like the target company's real domain. And in the case of this story, attackers managed to impersonate executives and trick employees into wiring funds. And as a result, well, around 46.7 million in funds were transferred to other overseas accounts. And actually, Brian Krebs of Krebs on Security really covered this story well back when it was going on. So, I encourage you to read more at this link if you're interested. And lastly, here we have Ukraine's power grid attack back in 2015. And so in December of 2015, well, Ukraine's power grid was targeted in a highly coordinated cyber attack attributed to the AP group Sandworm, which is associated with Russian intelligence agencies. And so this attack actually used spear fishing emails to deliver malware, which got the attackers initial access into the power grid systems. And once inside the network, the attackers were able to seize SCADA equipment and remotely switched off substations and disabled infrastructure components like power supplies and modems and other communicators. And in total, 30 substations were switched off and about 230,000 people were without electricity for some time. And this incident was really marked as one of the first known instances of a cyber attack causing physical disruptions to critical infrastructure at this scale. And of course, it all started from that spear fishing campaign. So hopefully you found these stories interesting. I encourage you to read more about them if you're so inclined. And hopefully it gave you a good idea into how important fishing analysis is and how important it is that we defend our organizations from fishing attacks. Let's quickly cover how email works. And it might seem a bit high level at this stage, but understanding how emails are transferred across the internet will help us with one of the most important strategies in email analysis. Determining sender origin and attribution. And chances are you've sent and received emails before, either in your professional or personal life. But have you ever actually dove in to understand the components that make up and deliver email messages? Well, if you have, then you'll probably breeze through this intro. But if not, I think this is worth discussing. And at its core, sending email operates on a simple yet robust system called the Simple Mail Transfer Protocol or SMTP. So, let's break down the process a little bit. When you compose an email and hit send, your email client like Gmail or Outlook or Thunderbird communicates with an SMTP server. And typically, you'll find these mail clients in either a desktop or a web application format. And this server acts as the post office for your email and manages it transfer to the recipient's inbox. So, in this example, let's say Bob, who has a Gmail account, decides to send an email to his friend Alice, who uses a Yahoo mail account. Well, he opens his Gmail account and then composes his message and addresses it to Alice's Yahoo email address. And so your email client connects to your email provider's SMTP server. And this server authenticates your identity and usually uses some sort of username and password to ensure that you have permission to send emails from this account. And we'll quickly cover the protocols in a second, but typically this is done over port 25, which is the standard simple mail transfer protocol port. And so when Bob hits send, his email client communicates with Gmail's SMTP server, which verifies his identity, usually through his Gmail username and password, and accepts the email for delivery. And so Gmail's SMTP server checks the domain part of Alice's email address, in this case, the yahoo.com, and queries DNS to find the IP address of the Yahoo's SMTP server. And then at this point, it's then forwarded to the recipient's SMTP server. And again, this is done by quering the domain name system or the DNS to find the recipient's email server's IP address. And so at this stage, the Yahoo's SMTP server receives the email and stores it in Alice's inbox, ready for her to access it. And finally here, when the recipient checks on the email, well, their email client, again, like Outlook or Gmail, in this case, Yahoo, connects to the server to download the email. And so there are separate protocols like POP 3 and IMAP that allow for the retrieval of email, but we'll touch on those in a second. And so when Alice logs into her email account, well, her email client connects to Yahoo server and downloads the email from Bob into her inbox. And so next, let's touch on the components that actually make up email. Specifically, we have email headers. And email headers are what essentially make up an email. And they're lines of text that provide information on an email's origin, routing, and how it should be handled. And you're likely used to seeing some of these headers in various email clients that you interact with. But the majority of email headers are abstracted from the user. And so when it comes to investigating potential fishing emails, well, email headers are one of the first things that we turn to. For example, here is an email that I opened in Mozilla Thunderbird, which is a mail client similar to Outlook or built-in mail apps that you might have used before. And upon doing so, we can immediately see some of the common email headers that have been graphically displayed within the email client. For example, on the right here, well, we can see the timestamp of when the email was delivered. And over here, we can see the subject line of the email. We can also see the recipient and the reply to header. And we're going to get more into email header analysis in a future lesson because it's really important to note that almost all of these headers that we see here can be spoofed by an attacker. So, we can't immediately trust what our email client displays. And now I mentioned that these were only a small subset of the actual headers attached to a typical email. And this is true. Just as a quick example, we can export the entire list of email headers to get a holistic view of what makes up an email message. And you can see we have a large number of headers here. And these are some of the ones we saw in our email client, right? We have the subject, the date or that timestamp, as well as some of the others here like the recipient. But we have so much more and even custom headers that we can see here. And there are many different ways to extract the email headers like this depending on your email client. And we're going to cover some common methods in the email analysis section. So next we have the email body. And the email body serves as the main content space within an email message. And it can include various elements like plain text or HTML or even multimedia rich content. And this section often includes not only textual elements but also hyperlinks and embedded images or HTML formatting. And so let's return to our example here in Thunderbird. And you can see the actual email body being rendered here. And it looks to be appearing as intended. We have some custom styling here for this blue bigger text here. We have a button that we can click on as well as a company logo. But like with a web page, this is rendered to the client and we can't actually see the components or the code that is making up the contents of this email. And so if we export this email or even just go to view the message source, well, we can scroll down past the email headers here and we're going to see the actual content or the HTML markup of this email message. We can see the content type here is in HTML and we actually have some valid HTML markup as well as CSS styling that is making up the contents of this email. And so what is an email address? Well, at its core, email addresses are unique identifiers assigned to individuals or organizations and entities, enabling them to send and receive email through email services. And so, an email address such as the one you see on the screen here, [email protected], is made up from multiple parts. So, first we have the local part or the mailbox. And the local part often represents the username or the alias of the email account holder. And it can contain various characters like letters or numbers or periods, even underscores and hyphens. In some cases, the local part might include additional information like the department or the role within an organization. And it might separate those with periods or hyphens. And most often, you'll see this done with different syntax. Right here we have Bob. So we have first name.ast name. Some organizations might do first initial last name. Or you might have specific mailboxes for finance or accounting. And so the second part here is the domain part. And the domain part of an email address identifies the mail server that hosts the email account. And it of course typically consists of two or more segments separated by periods such as example.com or company.co.uk. And specifically, this last segment here is known as the top level domain or the TLD. And this indicates the type or the category of the domain such as.com or.org or.net or even country specific tople domains like.uk. And so we mentioned DNS before. And so when an email is sent, the sender's email server will query the domain name system or the DNS to find the mail server associated with the recipient's domain. And so the DNS will then translate that domain name like exampample.com into the corresponding IP address of the mail server using the MX records. And so we mentioned that there are a couple of email protocols. And the email protocols are these sort of behind-the-scenes rules and standards that govern how emails are sent, received, and also managed across the internet. So these protocols are what enables that seamless communication between email clients like Outlook or Gmail or Yahoo and ensure that messages reach their intended recipients and allow recipients to query the mail server to retrieve those messages. So the first one we have here is SMTP or simple mail transfer protocol and this is the foundation of email communication. So, it's responsible for sending outgoing emails from your mail client to the recipient's mail server. So, when you hit send on an email, well, SMTP is the protocol that handles the transmission of your message across the internet. And so, it operates on port 25 by default, although encrypted versions like SMTPS or SMTP secure and SMTP over TLS operate on ports 465 and 587 respectively. But this is mostly for context. You don't really need to memorize these ports, although you should probably know that SMTP itself is port 25, which is pretty common. And so, next here we have POP 3 or Post Office Protocol version 3. And POP 3 is an email retrieval protocol used by email clients to download messages from the mail server to your device. And it works by connecting to the server and then downloading emails to your device and then deleting them off of the server. And so POP 3 is ideal for users who primarily access their emails from a single device, which to be honest is not that common anymore. And it operates on port 110. But again, like SMTP, there are encrypted versions of this protocol like POP 3S or POP over SSL that uses port 995. And lastly, here we have IMAP or Internet Message Access Protocol. And IMAP is another email retrieval protocol, but it offers more advanced features compared to POP 3. So with IMAP, emails actually remain stored on the mail server and your email client is able to sync with the server to then grab and display your messages. This means that you can access your emails from multiple devices and any actions you take like deleting or moving emails are then reflected and synced across all those devices. And so chances are you're more accustomed to using IMAP without even knowing it. An IMAP operates on port 143, but like with POP 3S, there is a TLS encrypted version of IMAP called IMAP secure or IMAP S, which uses port 993. Now, remember when we talked about how the SMTP protocol works in that the sender's mail server communicates with the recipient's mail server to deliver the message? Well, we use this nice graphic that I painstakingly put together. However, this is kind of a big abstraction of what actually occurs as the email traverses the internet. So, more typically, it's going to look something more like this. Well, actually, this is also kind of an exaggeration, but you can see that our message is going to be making many more stops along the way. This is because most likely an email sent from Bob on Gmail is going to need to travel through different routing points or mail transfer agents to reach Alice on Yahoo. And so, what is a mail transfer agent? Well, an MTA or a mail transfer agent, you might also see this called a mail transport agent, is a software application or server that's responsible for routing and transferring email messages between different mail servers. And so, when an email is sent, the MTA on the sender's mail server accepts the message, looks up the destination domain, and then determines the appropriate route to deliver the email to the recipient's mail server. And so when an email is sent from one domain to another, it might have to traverse through multiple MTAs over the internet in a relay before reaching its final destination. And something that we'll cover later on in the header analysis lesson, depending on the amount of MTAs that an email has to traverse in transit from source to destination, an email will have multiple received headers which should be read in ascending order chronologically. And so next we have a mail user agent or an MUA. And so an MUA is the actual software application used by users to compose and send and receive and manage email messages. So common MUAS include desktop applications like Microsoft Outlook or web-based clients like Gmail and mobile apps like Apple Mail. And so MUAS provide a user-friendly interface for actually interacting with email and allowing users to organize their messages or create drafts and set up filters. And so when a user sends an email, the MUA communicates with the user's mail transfer agent or MTA to transmit the message to the recipient's mail server. And so in essence, the MUA serves as the primary interface between user and email system. And we also have mail delivery agents or MDAs. And this is a component of an email system that's responsible for accepting incoming email messages from a mail transfer agent and delivering them to the recipient's mailbox. So we can think of it as the last agent in the relay that holds the email for the recipient to retrieve. And so once an MTA has successfully relayed an email to the recipient's mail server, well, the MDA takes over and performs actions like placing the email in the recipient's inbox or applying filters or sorting the message to specific folders. Essentially, the MDA is responsible for storing and organizing incoming email on the recipient's mail server. And there are actually two other functions in the email exchanger or the MX standard. We have the male submission agent or the MSA and the mail retrieval agent or the MRA, but they typically overlap with MUAS and MDAS respectively and they're not actually supported by the IETF standard. And so we'll just focus on these three above to understand the whole picture. Now, we're going to jump into the practical lessons on analyzing emails and we're going to do that primarily within our Ubuntu VM. And so there just a couple of utilities that we need to install first in order to do so effectively. And the first one is our actual email client, right? We want to have an actual email client on our system so we can open up and interact with email messages. And typically in the enterprise, you'll come across software like Microsoft Outlook or Outlook on the web. In smaller or more mediumsiz organizations, you might use Google Workspace and so you might be exclusively using Google Mail. However, in our case, we're going to install Mozilla Thunderbird, which is a free and open- source email client that's going to work perfectly for our demonstrations. And to do that, it's quite simple. So, I'm just going to open up a terminal window here. And from here, I'm just going to type in pseudo apt install, and it's just called Thunderbird. And with that ready to go, I'm going to hit enter. Type in my password. And this should just take a second to install. And there we go. It's finished. I'm just going to minimize my terminal here. And we should be able to find Thunderbird now in our list of applications. And so to do that, click on the Ubuntu logo here. In my case, it's in the bottom right. And you can see the newest app here is Thunderbird Mail. And so I'm just going to click on it to open it up. And when it starts up for the first time, it's going to ask us here to set up our existing email address. And so here, you can just click on cancel to sort of exit the setup here. We don't actually need to set up or configure an account in order to open up locally saved email files, which is what we're going to be doing in the following lessons. And unfortunately, it's kind of going to ask us the same thing every time we open up Thunderbird, but it's not really a big deal. However, now that we've installed Thunderbird, any ML or email files are automatically associated with the application. For example, I can just go under the fishing analysis folder here and just open up any email file. Right, we can see we have a number of email files here and we're kind of jumping ahead, but that's okay. But we can just double click on any of these files and it's going to automatically open up within Thunderbird, right? And so you can see now we're looking at the contents of this email. And in case that doesn't work automatically or it doesn't open up, well, we can right click on an email file and just click on open with. And from here, you can make sure to select the Thunderbird mail app. Now, one last thing with Thunderbird. So, let's just open it up again and just click on cancel. What we want to do here is just click on the hamburger icon here in the top right and go down to settings. And from the settings page, go down to the privacy and security tab and make sure that allow remote content in messages is selected. And this is just going to allow us to open up email messages with any linked images without automatically blocking them, which just saves us time when we're trying to open up multiple emails. And so we can just close that out now. All right. And so now we're going to install Sublime Text, which is a really powerful text editor for code and different types of markup. And when we do some manual email file and header analysis, well, we want to be using an actual code editor instead of relying on just our terminal. It just makes our lives so much easier. And so to do this, I'm just going to open up Firefox. And I'm going to do a search for Sublime Text. And this first result here at sublimeext.com just going to click on it. And I'm going to click here on install for Linux. And I'm going to link this below just in case the commands or the specific process changes. But we really just need to copy and paste a couple of commands here to first install the GPG key that's associated with the package and then just install the package. And so it's just really going to be a copy and paste job here. So, I'm going to copy this command, go back into my terminal, and just paste it in. All right, the next command, we're going to select a channel to use. And so, instead of dev here, I'm going to select stable. So, I'm just going to copy this command here, head back to my terminal, paste it in, and then next, we just need to run pseudoapp get update. And again, if you see this message here, we can just run pseudo systemctl damin-reload. And just make sure we update once again, just in case. All right. And the last command here is just going to be pseudoapp get install sublime-ext. So I will just paste that in. And we should have sublime text installed. And to confirm this again, we can go down to the applications menu and you can see we have Sublime Text. Nice. And now we can basically open up any file within Sublime Text. And so I'm just going to navigate here to the desktop folder under 01 fishing analysis under 01 header analysis and just run an ls to list out all of those email files. And to open up any of these files within Sublime Text, well, I can just run s for Sublime and then provide the name of the file. So, sample 1.ML. And so, now we're really jumping ahead, but you can see how we can sort of open up files within Sublime Text. And that's what we're going to be doing in the next lesson. And so, let's end it here and jump into the real lessons. As a sock analyst, chances are that you'll frequently encounter a number of different types of fishing attacks, all with varying objectives and means to achieve their goals. But ultimately, fishing relies on deception. And in general, we can break down attack types into several categories. Now, first we have information gathering attacks. And in an information gathering attack, well, you might be wondering what the entire point of the message was because it's not really an attack. These types of emails aren't trying to entice the victim to click on a link or download a file, but rather they're really just checking to see if a destination mailbox is in use and also if the user on the other end of that mailbox is prone to opening email messages. And if they can manage to get a response from the victim, they might also be able to somewhat passively collect data, which can often be done from an employes email signature, which can include things like their name, their job title, their phone numbers, and other personal or professional information. And this type of reconnaissance can be used to stage and craft a more convincing fish later on, or to tailor a specific attack to a specific individual or organization. So, here's an example of one of these information gathering attacks. In this case, I don't see any URLs to click on. I certainly don't see any attachments attached to this email, and I don't see any requests really for sensitive information. It just seems to be a very generic greeting and asking if I'm available. And there are many different ways that an attacker can gather information from a seemingly innocent email. For example, if they attempt to send an email to a mailbox that doesn't exist, well, they will typically get an automated bounceback or an undeliverable message in response from the email server. And this can be used to determine whether the mailbox is in use or not. And we can actually take a look at an example of one of these emails here. You can see here that I attempted to send an email to a non-existent email account. And because it couldn't be delivered, well, I got this email bounce back in response. Another way to do this is through the use of a tracking pixel embedded within the email's body content. And a tracking pixel is a tiny transparent image that gets embedded within the email content. It's typically like a one by one pixel image so that it's virtually invisible to the recipient. And when the recipient opens the email and their email client loads the content of the email, it also loads and requests that tracking pixel from the sender server. And this action allows the sender or the attacker in this case to collect various information such as the open rate. So the sender can track when and how many times the email was opened. And they can also log the IP address of the recipient. And in some cases, the sender can determine the general location of the recipient. And lastly, they can get device and client information. So the sender can gather data on the recipient's device type, their operating system and email client, and sometimes even specific operating or OS settings. Let's conduct a quick lab setup here to showcase a tracking pixel in action and also what data it can uncover. And now you don't need to follow along with this, so feel free to just watch. Now, I've set up a couple of prerequisites here. Now, first we have this tracking pixel.png image that I created in Microsoft Paint just by creating a 1x1 red pixel. Now, of course, in action, you don't want this to be a red pixel, but rather a transparent pixel so it doesn't appear in the email client. And next, I have this serve.py PIS script that I put together which uses the simple HTTP server in Python to set up a quick and basic HTTP server that I can use to log the requests. And in this case, I've added a specific directive so I can log the user agent. Now, this was mostly just done to set up an easy scenario here. In most cases, an attacker is not going to use a Python server, but most likely like an EngineX or an Apache web server to log these requests. And lastly, here I have this sample email that we're going to use. And if we take a look at the contents of the email, well, we just have some basic greeting and uh some generic email that is quite harmless. And now if we preview this email in our client, well, we're just saying hello. And that's all there is. Now, I'm going to start up our listening server here. And in a new tab, I'm going to open up our sample email again. And obviously, this would have been done when the attacker was crafting the initial email. But in this case, I'm just going to append this image to the end of our email. And you can see here we have an image tag. And within the source of the image tag, I'm adding a URL to our tracking pixel. And of course, in this case, it's just using local host because I'm not hosting this anywhere on the internet. It's just for this lab demonstration. And so once I save this, we're going to open up the email again. And on the right hand side here, we should see a request on our Python server. So I'm just going to double click the email again to open it up. And you can see the email has loaded. But if we minimize this screen, you can see we actually track the request here. And it might be really hard to see, but if we start zooming in, well, we can see this little red pixel at the bottom of our screen. This is our tracking pixel. And again, if we were smart and used a transparent image, well, we wouldn't see a red dot here. We would see nothing at all. So, while this email seemed completely harmless, well, we actually track some interesting information on our server. And so, we can see the actual IP address of the user that opened the email. And we can see here, of course, it's just this local host address because this is all being done locally in a lab. But if this was an actual organization's email client that opened up, well, we would see the IP address. If this was a user opening the email at their home office, well, we would see the IP address of their home office. And of course, we have the request timestamp. And this is when the recipient opened the email and the email client itself made the request to gather this image. And so, if we close this email and open it again, we should get another request with another timestamp. And there we go. There's our second request. So, not only are we getting the IP address of the opens, but we're also getting when and how many times it was opened. And lastly here, of course, we are getting the user agent of the actual email client. And we can see some very interesting information here. I'm just going to copy the entire user agent string and I'm going to parse it using a tool that we looked at before. So in this case, I'm going to do a quick Google search for a user agent parser. You can see this what is my browser.com parse a user agent string. Well, let's go here. And under here, I'm just going to paste in the user agent string that we captured. And if we parse this, well, we almost didn't even need to because it's so verbose on its own. But you can see the client that opened our email was Thunderbird. And we have the software version. So we have 1510.1. We can also see the layout engine and the version of the layout engine. We can see the operating system. So we buntu Linux. So we were able to enumerate all of this information as an attacker just by introducing a one by one pixel within our email. So I hope that was somewhat interesting and hopefully demonstrated the reconnaissance technique pretty well. So we also have credential harvesting attacks and these are actually a very common type of fishing attack and likely one that you most often associate with fishing emails in general. So these are fishing attacks designed to trick individuals into divulging sensitive data like their username and password. So their credentials, right? Or even their credit card numbers or other personal data. And typically this is done through a malicious web page or what we would call a credential capture website. And the fishing email itself often contains some sort of call to action, right? So maybe a button or a URL to click on. And this link or this URL usually directs the recipient to a fake website that attempts to closely resemble a legitimate one. And honestly, in the field, the most common one you're going to see is a Microsoft login page because so many organizations use Microsoft products and so many organizations are moving to their cloud services. But of course, this is just a fake website and it's designed to capture a victim's credentials and send them over to a server that the attacker controls. And maybe if the attacker is really fancy, they'll then redirect the user to the legitimate Microsoft website or whatever it's trying to impersonate as to make it appear more legitimate and hide their tracks. For example, here is one of those credential capture fishing emails. We can see here in the subject line that this email is supposedly related to our Microsoft account and we seem to have identified some sort of unusual sign-in activity. And we can see some information here saying that apparently we've had a sign-in on our Microsoft account well from Russia. And if we think about some of these social engineering tactics here, well, we might have some urgency in this case because apparently someone is in our account and we need to look at the activity. And so we have this call to action within the email that says view activity. And if we hover over this button, we can see the URL that's going to take us to this mc4-2.verell.app. Now immediately this does not look like a Microsoft related web page. But the typical person might not notice this hyperlink, right? They might just see this button and click on it. And so let's do that. Let's see where this link takes us. And so if we click on the link, well, we're delivered to this web page, which seemingly looks like a genuine Microsoft login page. We even have the Microsoft logo, the signin, and honestly, even the background here, this all looks to be a legitimate Microsoft page. For example, if we go to the real Microsoft page and try to sign in here, well, we get a very similar web page, right? If we go back and forth uh and get the zooming correct, if we go back and forth here, well, it actually looks pretty similar. and pretty convincing. And someone that just got an email indicating someone's in their account from Russia, well, they might not notice the little details here, like the font not being exact or some spacing issues. And of course, if we were to put in a fake username here and click next, surely it's going to ask us for a password. And if we type in a fake password here, and before I hit sign in here, what I'm going to do is open up the developer tools under the network tab because I want to see where our credentials or our fake credentials are going to get sent to. And of course, this is not something we should include in our methodology, but I just want to demonstrate what an actual credential capture web page looks like and how it operates. So, let's just hit sign in here, and we should be making a post request. There we go. And of course, we're getting this fake your account password is incorrect. Surely, it's not actually communicating with Microsoft servers to determine if our credentials were correct, right? But if we open up this post request and expand this a little bit, we can see we're making a request to this mc4.onrender.com on render.com specifically to this user/ad endpoint. And if we look at the request, well, we have our email and password within the raw data that we sent over. Now, of course, this is not an official Microsoft website and likely the attacker is using some sort of legitimate service like on render to actually submit data, right? And if we were an actual victim falling for this, well, the attacker just got our credentials, right? They were sent over to that server. So, next we have malware delivery. And in a malware delivery fishing attack, also known as a malicious attachment, uh, of course, this is a type of fishing attack where the attackers use some sort of email that contains an attachment to distribute malware infected files to their victims. And honestly, often this is done under the guise of like a fake invoice sent by supposed customers or third parties. And you know, depending on the amount of effort and research done by the attacker in the reconnaissance phase, well, an attacker might be able to actually spoof real customers that a victim interacts with. And these attachments are often things like PDF documents or spreadsheets or executable files. And it's either infected with malware itself, or maybe it contains malicious macros if it's an office document, or maybe it's just a benign and normal office document that simply contains a URL inside it to download a malicious file in something what we would call a driveby download attack. And a dry download is where malware is automatically downloaded onto a victim's computer without their consent or knowledge, simply by visiting a compromised website. And of course, as we discussed during the fishing case study section, well, these attachments or files can often lead to devastating ransomware attacks or deploy things like remote access trojans that compromise a victim's device or demand money or steal sensitive information. And we're going to cover analyzing fishing attachments in more detail later on. So, let's look at another example here. So, based on the subject line, this appears to be a due invoice payment. And based on the contents of the email, well, it appears they've attached some sort of invoice or wire slip for us to take a look at. And if we look at the attachment here in our email client, we can see we have this quotation file. And an ISO file is typically an image of an optical disc, like a CD or DVD drive. But it's actually a common technique for attackers to embed malware inside of ISO files and distribute them through things like fishing emails. And if we were on a Windows endpoint, well, we might be able to download this file from the email, mount it to our system, and then execute the malware. Now, we briefly covered spear fishing before, but just to recap, spear fishing is a targeted form of a fishing attack in which attackers craft personalized emails aimed at specific individuals or groups within the organization. And similarly, we have whailing attacks. And whaling takes spear fishing a step further and specifically targets high-profile individuals within an organization like executives or senior managers or individuals that would likely have access to sensitive files or have more permissions in general. And we also covered things like fishing and smishing and quishing. Now fishing of course is short for voice fishing and is a type of fishing attack that's conducted over the phone. So in a fishing attack, well attackers are going to use social engineering techniques to manipulate individuals into revealing sensitive information like passwords and again like credit card numbers or PII. They typically do this by impersonating a trusted entity like a bank or government agency or even IT staff. Similarly, of course, smishing is a combination of SMS and fishing. And this is a type of fishing attack conducted via text messages or SMS. And in smissioning attacks, attackers will send deceptive text messages to individuals, typically containing a link to a malicious website or promoting the recipient to reply with some sort of sensitive information. And of course, lastly, we have quishing or QR code fishing, which is a type of fishing attack that exploits QR codes to trick individuals into visiting malicious websites or downloading malicious content. And with fishing attacks, well, attackers are going to create QR codes that when a victim scans them with their smartphone or some other QR code enabled device, it will redirect the user to a fishing website or a credential capture page or even just initiate the download of some sort of malware. And quite honestly, this is so easy for attackers to do. I just Google generate QR code and I have all these options to choose from. So, I'm just going to click on this one here. And you can see that we can generate QR codes for all these different types of things. For example, a URL or we can send an email with predefined text or things like displaying a PDF or images. So, let's do a quick example here with a URL. Suppose we've set up a malicious website on example.com. Well, we could just put in the address here and suddenly we have this QR code that we can then distribute. And sure enough, if you open the camera app on your phone and scan that QR code, well, you're going to be redirected to example.com. Now, of course, in this case, it is not a malicious example, but of course, we can put any URL here, right? So, any attacker controlled URL can quickly and easily be turned into a QR code. So, next we have business email compromise. And this is also sometimes known as CEO fraud or email account compromise and is typically one of the most financially damaging fishing attacks. And in a business email compromise attack, well, an attacker might either spoof or actually gain access to a trusted individual's email account and use this credibility to stage malicious requests. And these requests can often come in the form of things like unauthorized wire transfers or invoice scams. And an example we covered before is uh like a company CEO asking an assistant to purchase gift cards and then send the serial numbers of those gift cards over to the attacker. And we even covered the 2015 Ubiquity Networks attack which of course led to the loss of 46 million which was in fact a business email compromised fish. And lastly here, well not all suspicious or unwanted emails are actual fishing attempts. And you know, spam emails, they might not be blatantly malicious in nature, but they are typically unsolicited bulk emails that are sent to a large number of people, typically for commercial purposes like advertising or uh promoting fraudulent or sketchy schemes or dating websites or things trying to sell like random junk, right? And of course, spam emails can be pervasive and persistent, and they can be a nuisance for employees. And again, while they're not typically malicious, they can still carry risks and implications. For example, it's possible that an email that just appears to be an annoying spam email is actually an information gathering email used to perform reconnaissance on a future fishing target. So, in general, these are the common types of fishing attacks you'll see in the wild. And in the next video, we'll look at how to actually identify fishing attack techniques, and we'll cover things like what attackers actually do to go about their objectives. So, we covered the different types of fishing attacks that you might come across in the field, but what specific techniques do attackers employ during their fishing campaigns to obiscate their methods and deceive their victims? Well, let's take a look at a couple examples here. And although the list of techniques and possibilities remains to grow in the field, we'll take a look at the most common ones that you might come across. So, first we have pretexting. And pretexting is a social engineering attack used by attackers to manipulate individuals under false pretenses. So in pretexting scenarios, an attacker will create some sort of fabricated story or scenario to gain the trust and cooperation of their targets. And they'll often do this by exploiting human emotions like curiosity or in general the human willingness to want to help others. And many of the methods that we covered previously can all play a role in establishing a credible pretext. So things like spoofing or impersonation or establishing credibility through using trusted logos or messaging within a fishing email. So maybe it's an email impersonating the HR department asking employees to provide their bank account information so that they can then update their records to ensure they get paid on time. And similarly we have spoofing and impersonation. So as we just mentioned spoofing and impersonation are common techniques used by attackers to deceive recipients and increase the credibility of their emails. And like I said earlier, because almost all of the email headers can be completely modified and spoofed on the attacker's end before it's sent, we typically tend to see a couple different variations of spoofing. So we have email address spoofing. And this is where the attacker will spoof the sender's email address to make it appear as though the email is coming from a legitimate source. And we also have domain spoofing. So in addition to spoofing an individual's email address, attackers might spoof an entire domain to make their fishing emails appear as though they originate from a reputable source. So they might actually register domain names with similar names to legitimate companies and they'll try to use this brand recognition to trick people into believing the email. But attackers can take this one step further with URL manipulation. And there are actually a number of URL manipulation techniques that you should be aware of when you're analyzing suspicious emails because they're very easy for attackers to take advantage of and sometimes it's almost impossible to recognize without careful inspection. So the first one here we have is URL shortening. So attackers can leverage URL shortening services in emails to obscure their malicious links or get around email security features. And honestly, this is surprisingly easy to do. And while there are some security solutions out there that will of course detonize and analyze the true destination of these shortened links, well, this isn't always the case. For example, let's showcase one of the most popular services for shortening URLs, Bitly. But of course, there are many others out there like Tiny URL or short.io and many more if you just Google. And bit.ly is a service that allows us to do things like shortening URLs or generating QR codes which we showcased in the previous video. So if we click get started for free, well, we can sign up for a free account here. And once we're signed in, we're taken to this dashboard where we can do a number of different things. So let's get started and create a short link. So let's say we wanted to create a shortened link for TCM Security's website. Well, I'll just paste in the destination there. We can give it a title and we can actually create what is called a custom back half and this is going to be what is shown in the URL itself rather than a you know automatically generated string. So we can actually set this to whatever we want. And for example if I was trying to impersonate a specific bank well I might call this banking services or something similar right as an attacker. But let's just leave it with totally amazing website and scroll down to create here. You can see we have created the link at bit.ly/totallyamazam amazing website. And if you were to type this into your browser, well, you're going to be redirected to the TCM Securities website. And so you can see if we were to edit this URL to something malicious, well, we can just give people this link and they would be in the dark as to where this link actually takes them. But there are some services that we can use to expand this link, right? So if we go to unshorten.it it. Well, we can paste in our bit.ly link here and we click on unshorten it and you can see it actually detonates that link for us and follows all of the redirects. So, in this case, we can see where it's actually going. So, next we have subdomain spoofing. And subdomain spoofing is a technique used by attackers to deceive users by creating a fraudulent subdomain that mimics a legitimate one. And this method capitalizes on the trust that users have in well-known domains or subdomains. And this is actually a very common tactic. So suppose a malicious email that is sent from a real mailbox of google.mmalicious site.com or within a URL in an email that leads to something like facebook.loginsystems.co.uk. In this case, these are legitimate domains. The headers don't even need to be spoofed. These are simply just malicious subdomains registered under a non-affiliated base domain. So the companies that are being impersonated like Google and Facebook have no affiliation with this base domain, but the attacker makes it look as though they do. So someone not paying attention might immediately assume the URL is safe because it begins with Facebook or contains Google in the URL. And these are organizations that they would typically trust. So next, let's talk about a really interesting attack, homographs. Now, technically speaking, in grammar, a homograph is a word that shares the same written form or spelling as another word, but has a different meaning. For example, bas in the fish, or bass, the instrument. A similar technique is sometimes done with domain names to impersonate an actual legitimate domain with a malicious copy. So, in the context of fishing attacks, attackers can use characters from different character sets like cerillic or Greek or Latin that resemble legitimate characters in a URL. This makes a URL visually similar to the legitimate one but leads to a different website. And so this specific method is sometimes referred to as an internationalized domain name or an IDN homograph attack. And so can you tell the difference between these two domains? In this case with this font and rendering you actually can't. But there's a slight difference. In the second domain, the C character has actually been replaced with the cerillic lowercase C, which looks identical to the Latin lowercase C, but is a distinct character in Unicode. So, visually, both these domains appear the same, but they are technically different due to the character used. And so, how do attackers actually come up with these domain names? Well, they might use something like this homoglyph attack generator. So, first we would type in the name of the legitimate domain that we're trying to mimic. And you can see here as we were doing that, it generated all these different options for us. So for example, we can replace the C with all these different options or maybe the M or the S. And if we scroll down, we can see our generated domain here. So obviously we chose a capital M here, which is not very smart. We can see some of the other characters are pretty close. On the topic of homograph attacks, we have the general technique of typo squatting. And typo squatting, which is also known as URL hijacking or domain squatting, is a technique that exploits common typographical errors made by users when looking at domains or URLs. And so by registering domain names that closely resemble popular or well-known websites, well, an attacker can trick a victim into thinking that an email was sent by a legitimate sender or a URL in an email is legitimate as well. For example, instead of linked.com, an attacker could purchase and register linked.com with the simple omission of the second I character. And you know a user who is not paying close attention might not notice this in an email. And there are actually different types of typos squatting techniques and we can use a service like DNS twist to identify potential typos squatting vectors for our or any domain. So this is actually a Python tool in which I'll have linked down below but we can run it to find lookalike domains that adversaries can use to attack us. Alternatively, this is actually something hosted on the web as well. So we don't actually need to download this and run it locally. So in this case we can just put in a URL and it will scan it for us and it will start generating all these different types of typo squatting vectors. And we can see here the ones with IP addresses and name servers have actually been registered already. We have different types here, right? We have additions. So in this case we have linked N with two N's. And if we scroll down we can actually start to see some homoglyph or homograph attacks. And this one is omitting the I character in favor for something that looks somewhat similar. And you can see just how many of these have been registered and probably used for fishing campaigns in the past. But many organizations will proactively purchase some common typos squat domains to prevent malicious uses. For example, facebook.com with only one O redirects to the legitimate facebook.com. Goggle.com without the second O redirects to google.com. And actually, one of my first projects as a junior security analyst years and years ago was to build a tool very similar to that DNS twist tool. And it was so that our sock could proactively get alerted on potential typos squatting domains if they were to be registered and to also provide a report on domains that we could proactively purchase to mitigate these attacks. And so next here we have encoding. And encoding is a technique that can sometimes be used by attackers to obiscate malicious content or evade automated detection. And sometimes this is done on the email body content itself, right? It could be using something like B 64 or URL encoding or HTML encoding to slightly obiscate the contents of an email message until it gets rendered in the email client. Just as a very simple example, let's open this encoded attachment here. And you can see we have a very simple email here with a hyperlink to proceed to wallet verification, which of course this leads to a credential capture page. And although it looks very simple when it's rendered, let's take a look at its source to see what components make up the email. And if we scroll down past the normal headers, well, we're going to see a very long string of seemingly random data at the bottom of this email. And we don't actually see what we saw in our email client, right? We don't see this hyperlink with the proceed to wallet verification. Instead, we just see this long string of text, which as we can infer from the content transfer encoding header here, it is a string of B 64 text. So, let's copy this long string. So, I'm just going to open a terminal window here, and I'm going to echo out that long B 64 string that we copied. And of course, echoing it out like this is not going to do anything interesting. But what I can do is echo this out and pipe it to the base 64 command. And then I'm going to provide the tac d argument to decode. And you can see here it actually managed to decode that URL that we saw in the email when it was rendered. And so that was just a very simple example of B 64 encoding. But we're going to cover encoding in more detail later on in the course. As we discussed previously, and we'll do so in more detail shortly, a common technique in fishing emails is to include a malicious attachment or even a benign attachment that eventually leads to a victim downloading a malicious payload and being compromised. We also have abuse of legitimate services. So, interestingly, an attacker doesn't always have to rely on their own means to deliver and host malware and weaponize content shared within their emails. Attackers frequently exploit legitimate file sharing and collaboration services such as Google Drive or Dropbox and many others to facilitate their fishing campaigns and distribute malicious content to users. And so by leveraging the trusted reputation of these platforms, attackers can evade traditional email filters and security controls, making it easier to get to their victim's inbox. And so an attacker would upload their fishing content like their malicious document or an executable to a file sharing platform like Google Drive or Dropbox. They might even password protect it and zip the file so that it can't be sort of detonated by any automated means. They'll then distribute the links or the public sharing links to these hosted files within their fishing emails and include some sort of call to action for users to click on the links and access the malicious content. And because the URL is legitimately coming from Google or Dropbox and the former almost always being trusted within environments, maybe not so much for Dropbox, but definitely Google, these URLs will often go undetected and there's nothing preventing users from downloading these files until their endpoint security hopefully kicks in. So to hopefully demonstrate the use of a legitimate service, well, I'm using a site called Fish Tank. And you can think of this as a big repository of potentially malicious URLs that people can submit from all over the world. We're going to cover this in more detail in the URL analysis lesson, but for now, I just looked at some of the most recent submissions, and I can already see a docs.google address right here, indicating that someone is trying to abuse Google Docs to fish someone. And so, I'm just going to click on this submission right here, and I'm going to copy the URL to see if we can find out what's being hosted. And so, again, this is something you should not do, but considering I'm in a VM, and I'm just doing this for research purposes, I'm going to see what is actually being hosted here. Okay, so very interesting. It appears to be hosting some sort of image. And this is of course an Amazon account lockout image. This is not actual HTML. This again just appears to be an image of some sort. But it also has a hyperlink. And if we just copy this link, well, I'll just showcase it in a terminal window. I'm going to paste it here. And we can see some very interesting things here. So it looks like it's using an actual google.com base URL here, but it's passing in an additional uh shorten URL using bit.ly within this query parameter. And so we could go ahead and try to unshorten this like we've done before and see what is actually on there. But I think this sort of demonstrates the point. And in this case, we have a fishing attempt with a malicious URL hosted on the docs.google.com domain, which is most likely not something that's going to get flagged within many organizations because of course this is actually belonging to Google. And we can see the certificate here is actually signed by Google Trust Services. And lastly here we have farming. And farming is typically a two-step technique. The first being more so what we've covered before where an attacker will redirect a user to a fraudulent website that closely resembles a legitimate one. And so as such, this technique is often used to perform credential harvesting attacks. But it's a two-step process because unlike other methods of spoofing or impersonating, which we've talked about, farming actually requires configurations or malicious code to run on a victim's computer or within their DNS server to redirect the actual traffic to the attackers's controlled website. And so we have malwarebased farming which occurs when a user unknowingly downloads malware like a Trojan or a virus. And this malware can then get in front of a user's web traffic and redirect them accordingly. On the other hand, DNS server poisoning involves manipulating the actual DNS servers or a user's local host file or caches to then redirect the user to a fake IP address instead of legitimate websites. In the immediate lessons following this one, we're going to cover a number of techniques and tools that we can use to extract artifacts and analyze emails. However, the key as I've mentioned to effective email analysis lies in establishing a structured methodology that we can consistently apply across various situations irrespective of what tools we have available to us. Right? So, your methodology doesn't have to be exactly as follows, but definitely consider several of these essential steps as a good starting point. So, first we're going to need to do some initial triage. And so upon receiving a suspected fishing email, well, the initial step is to conduct triage to quickly assess its potential threat level. So this involves identifying key attributes like the sender details or the subject line or other urgency indicators that we can identify. And so triage helps us in determining the appropriate level of response and the appropriate timing of a response and allocation of resources to do our further analysis. So to put it simply, in the triage stage, we need to quickly assess and prioritize potential impact, which will allow us to focus on what's most pressing. For example, maybe we have an email that initially looks like spam that was sent to one employee versus a reported email containing an attachment that was sent to a number of executives. And so next, as we alluded to earlier, the header of an email contains valuable metadata that we can use to quickly analyze and assess its true origin. So, an examination of an email header will involve things like looking at the routing path an email took through the internet or the sender IP address or the domain authenticity and maybe if we can identify anomalies or signs of spoofing. And so, when we do sender examination, well, that's going to include things like verifying the sender's identity. For example, you know, is this really a Microsoft owned domain? Well, if we do a reverse DNS lookup, what is the email server that returns? Is it Microsoft owned? Did this email pass an SPF and DKIM check? Well, these are all things that we're going to cover in the next lesson. And so, next, we want to do some content examination. And this involves analyzing the body of the email for any suspicious elements like grammatical errors or generic greetings or unusual or awkward language. And sometimes we can catch some immediate red flags, even as far back as in the initial triage stage. And these red flags might really give an email away as being fishing. However, we can't always assume, which is why we have to have this methodology. And we can also look for any common social engineering techniques that we looked at earlier. So things like urgency or trust or authority or scarcity. Fishing emails will often contain course of language and requests for sensitive information or call to actions. Next, we'll want to look at the web and URL artifacts, right? So URLs embedded within fishing emails need to be analyzed to determine their legitimacy and their destination. If we're faced with an oddlooking or maybe worse a shortened URL, well, we can employ various techniques such as URL parsing or URL detonation and scanning and domain reputation checks to assess the risk associated with accessing the link content. And like with any URL artifacts that we find, well, any email attachments also need to be investigated. And so, we'll employ malware analysis techniques like sandboxing and file signature analysis and behavioral analysis. These can all be done through manual and automated scanning means. But most commonly at least the file hashes need to be safely extracted as artifacts and reviewed through a malware database to determine if it's a known malware sample. And in addition to the hands-on analysis we perform, well, we should also include some holistic analysis and consider the broader organizational context as well as recent security incidents to gauge the credibility of a fishing email. So we can look at patterns within our organization or look in our ticket system for recent or similar fishing emails. You know, maybe we assess the scope and look at the IoC's or artifacts that we've identified and perform almost a mini threat hunt over the organization's email system to see if there are similar attempts going on. And maybe we can identify recurring themes like a sender's address or tactics used by threat actors that will allow us to more efficiently and proactively integrate defense measures. And speaking of defense measures, well, upon identification and verdict of any fishing attempt, well, we need to take either reactive or proactive defense measures or both, depending on if the attempt was successful or not. So, reactive defense measures are going to include things like invoking incident response procedures for containment and mitigation and remediation in the event of a successful fishing attack. For example, if a user was successfully fished and they provided their credentials, well, we need to initiate instant response procedures to temporarily disable their account or review their login history and change their credentials or rotate any keys and even perform a full system scan or reformatting depending on a deeper investigation. And on the other hand, proactive defense measures will involve things like implementing technical controls like email filtering or DNS blacklisting and endpoint protection based on the IoC's and artifacts that we've identified. And we should also be educating users about fishing awareness and provide guidelines on how to identify suspicious emails and how users can report incidents quickly to the sock. And lastly here, this brings us to documentation and reporting, which in reality should be a step that is followed through each stage of the methodology, not just something that we shoehorn at the end. So while we investigate emails and collect artifacts and analyze our senders and even look at URLs and attachments, well, we need to keep detailed notes and update our tickets accordingly and accurately. And if we take any defensive actions, well, we need to document these as well. Like if 6 months down the road a stakeholder is asking why the sock block a certain domain or an email, well, we need to be able to go back and justify our actions. Our documentation needs to be clear and thorough. So much so that any other analyst can come by after us and make the same determinations and verdicts based on our findings. So, as our investigation progresses, we should be continually updating the status inside our ticket management system. and we need to make sure to close out the tickets and communicate to users on the reported emails verdict as needed. Let's start analyzing some real emails and learn how we can use header analysis to identify the sender of an email as well as their legitimacy. If you recall, email headers are just simply text files with multiple lines indicating a header name and a header value. Because of this, we can essentially use any text editor or even command line tools to view the header information of an email as long as we have a copy of the email saved. In some cases, depending on the email client, we can actually view these headers directly in the program itself. For example, in Thunderbird, we can just go under the view tab here and click on message source. In Gmail, for instance, we can just hover over an email under the more icon and either go down to download message to download AEML file of the email or we can go up to show original. And if we click on show original, this is going to give us a full output of the email headers, which we can then download or copy to our clipboard. on an Outlookbased system, specifically Outlook on the web, we can do something very similar where we head over to these three dots for more actions. Click on it and we can then go to save as if we want to download the email or alternatively we can go to view and click on view message source. And by clicking on this again, we will get an output of the email headers which we can then copy. And you can easily look up these steps to view email headers depending on the clients and the tooling that your organization uses. Additionally, if you're using some sort of ticketing system like Jira or Service Now to handle fishing reports and you have some sort of workflow in place that allows users within the organization to report suspicious emails, what typically happens is that the email will automatically forward itself as an attachment to a fishing analysis mailbox. And there might be some further automation in place that will subsequently create individual tickets or alerts within the ticketing system to create cases for analysts to then triage within these tickets themselves. The extracted email and typically within a ML file format will be available to view and download. And this file contains all of the original headers that we're interested in. And note that if a user forwards an email the typical way through pressing the forward button in their email client, in most cases, the original headers will be lost, which makes the analysis portion much more difficult. This is why it's important to forward the email itself as an attachment, which is typically an option in email clients if it's not already being done through some sort of automatic workflow. So, now that we have some copies of emails we want to investigate, we can use a number of different tools or methods to view its contents. So, first for this lesson, navigate to the fishing analysis folder on the desktop and then open the header analysis folder. And from here, let's start with sample 1. ML. So, we just double click on this to open it up in Thunderbird. And you might see this connection failed. You can just ignore that message, but eventually the email will open up as seen above. So, this is the first email that we're going to be analyzing. And so, we can see what it looks like initially. We can see this Chase Bank logo. It appears to be asking us to restore or reactivate our account. And we can see some of the common headers. So we have the from field here which is [email protected]. We have the two field which is bob sanders. The subject line so your bank account has been blocked as well as the timestamp over here on the right which we've looked at earlier. So these are some of the common headers that we've seen before. But I mentioned it's essentially just a text document that makes up email messages. So if we go back to our folder, I'm just going to rightclick and click open in terminal. This is going to open a terminal session in the folder that we were looking at. And from here, I'm just going to run an ls to list out the contents. And we can see the sample emails that we have in this folder. I'm simply going to cat out the sample one email file. And just as you can see when we were exporting the source of the email itself, we're getting the same information here. So this is the HTML markup that is making up the email body. And if we scroll up, all we can actually get to the actual headers. So much so that we don't need to just cat out the file. If we wanted to find something like the from header, well, we could just run a GP command like this. And we can see immediately we get the from header returned with alerts at chase.com. But again, working with it in a command line like this isn't ideal. So what we can also do is open it in a text editor like Sublime Text. So to do that, I already have Sublime Text installed in this lab. So all we need to do is just run the suvl syntax here to open up Sublime Text and provide the file that we want to open. Sample 1.ML. You can see here we have the email message opened up in Sublime Text. But when we open up an email in Sublime Text, by default, we don't get the benefit of syntax highlighting that makes our lives easier. But fortunately, Richard Davis, the founder behind 13 cubed, developed a super useful package that we can install in Sublime Text to assist with this. And I will have the link down below. But essentially, this is a syntax highlighter plugin that we can use specifically for email messages. So, all we need to do is go up into the toolbar here under tools and click on install package control. We'll get this message that it was successfully installed. And then we want to press control shift and p to open the command pallet. We just want to type in install package. And then we're going to click on this option here. And then we can just start typing in email. We can see the first option here is the email header syntax highlighting plugin developed by 13 cubed. And this is the one that we want to install. So I'm just going to click on this. And now once we go to our syntax here in the bottom right, well, it's currently set to plain text. If we click on this and we start scrolling up, well, we can see this new email header option here. So, if we click on this, we can suddenly see our file becomes much more readable. So, we have some color and highlighting here that is separating out the header name versus its value. And we have an additional color here to separate extended or custom headers, which we're going to talk about in a bit. And next, I quickly wanted to look at the ANA or the internet assigned numbers authority page, specifically the standard that outlines message headers. And so this link contains all of the various standardized message headers, including their names and descriptions and any associated protocols. And you'll see that there are tons and tons of headers here. Some of which are more common and some not so much because I don't want this lesson to be a week long, but we're going to focus on the most common and most useful and important headers that you're going to want to know about. So let's get back to the email and take a look at some of these common headers. So the first one here is the date. The date header in an email specifies the date and time when the message was composed or sent. We'll often want to document the date and time of an email for our records. Whether it be this timestamp directly from the header or from the email client or from the ticket that was created. Knowing when an email was delivered can be very useful in performing email searches across the organization for similar emails or for correlating other suspicious activity that might have resulted in a fish like in our SIM for instance. Right above this we have the from header. The from header, as we're likely familiar with, specifies the supposed sender of an email. This is the header that will be displayed in email clients to show who sent a specific email. However, because the from header can be set to any arbitrary value, well, this is one of the most common headers that attackers can spoof to make it look like a fishing email came from someone else or a trusted organization. But we should still document this though because we can use it to find discrepancies as well as use it as an artifact to search off of. So, next we have the subject line. And again, we're used to seeing the email subject, which is of course the subject that appears in your email client when you receive an email in your inbox. Again, this is a useful header to document because we can almost think of it as a signature or a fingerprint of an email should we determine it to be malicious. For example, we can use a subject line to perform searches against our email gateway and look for other associated emails or in rare cases actually block specific email subject lines from entering our organization. And along the lines of fingerprinting an email through artifacts, well, we have the message ID field as you can see here. And the message ID header is a very useful one for us because it is a unique ID generated by the first MTA that the message traverses through. And these message IDs should always be unique by the server that generates it and pertains to a single version of that email. That means if we ever find a duplicate message ID in our email gateway, well, it could very likely be an indication of something malicious going on. And these IDs are made up of two parts. And so anything before the at sign here or this left side of the ID, the standard documents that it should be a unique identifier, although there are no specific algorithm requirements in the standard. And on the right hand of the message ID, but we expect to see the domain name or the IP address of the host in which the message identifier was created. That means in theory if we identify a specific mail system domain that the email originated from but the message ID contains a different domain name well again this could be a hint that the email was forged. We also want to document the recipient email address during our triage stage because this is where we can determine scope and we can do this through the two header. If we have multiple users that received the same suspicious email, well we need to be aware in case we need to take action across anyone else that received it. And you might not always be able to see multiple emails listed under the recipients. It's quite trivial for an attacker to utilize blind carbon copy or BCC to include multiple recipients and prevent each of those recipients from knowing who else received the email. In this case, this is where our timestamps and subject line and from headers become useful to have documented so we can perform our own search at the email gateway level. And next here we have the reply to address. The reply to address in an email message specifies the email address to which replies should be directed to when a recipient responds to it. And it's different from the from address which indicates the sender of the email. And of course, there are legitimate uses for a reply to address. But many times if an attacker is spoofing a legitimate domain, well, they have to specify a different reply to address because they don't actually have access or have control over the legitimate domain that they're spoofing. For example, if an attacker has spoofed accounts@ microsoft.com in the from header, well, any replies to this email would not actually be received by the attacker since they don't have control over the actual accounts@ microsoft.com mailbox. Instead, an attacker would commonly insert the address of a mailbox that they own under the reply to field, such as [email protected] to ensure that they capture any replies. And we also have the return path here. And this header is also known as the envelope sender address or the bounce address. And it specifies the email address to which bounce messages or delivery failure notifications should be sent. Similar to the reply to header, we can check if this header matches what we saw in the from header. And again, sometimes there are legitimate purposes for why this doesn't match. But if an attacker is using a service to mass fish a number of potential victims and doesn't care about reconnaissance, they might want to direct the bounceback somewhere else. And so you'll notice with our syntax highlighting, we can see these standardized headers in one color and these X-Type headers in another color. And these X-Type headers are also known as experimental or extension headers. And often you'll see them referred to as custom headers as well. And these are additional headers that don't fit within the standards adopted from the AA, but they are sometimes used by mail providers or security solutions to add additional functionality to email clients and filters and do things like spam checks or tracking or authentication results and other additional metadata. And we have some that are particularly useful for us, but not always present. For example, here we have the X sender IP. Now, this is one of the most commonly seen X headers out there and is actually pretty useful for us as an investigator if it's present, but of course, it's not always present. You might also see a header called XO originating IP and it essentially serves the same purpose. And again, you might see this or not or one or the other. It entirely depends on the email infrastructure. And the Xorinating IP or the X sender IP header typically indicates the IP address of the device or server from which the email originated from. and it's added to the email headers by the sender's email client or the message submission agent. And the catch here is that certain providers will not include this header. For example, Google does not include the header while Microsoft typically does. And once we obtain the originating IP address, we can perform certain investigative actions like geoloccating it to determine where the server is geographically and what autonomous system organization or ASN does it belong to. We can also check the IP's reputation or perform a reverse DNS lookup to identify what domain or host name the mail server resolves to. And now if we don't have access to this header, there are still ways in which we can retrieve the originating IP address. The most useful and reliable way is through the received headers. And we have to scroll to the top to see these received headers. Now, I wanted to cover some of the more basic headers to get a feel for what makes up an email. But there is one type of header that in our investigations is going to arguably be the most important header that you're going to come across. And that is of course the received header. And now the main thing you'll notice here is that there are multiple received headers. And this is normal and you'll typically see more than one. If you remember when we talked about how the email protocol works, we mentioned that emails typically go through a relay of mail servers or MTAs as they are routed from sender to recipient. The number of received headers you see are going to vary depending on how many MTAs the message had to traverse within its journey. And so each email server that handles the message adds its own received header, creating a chronological record known as the received chain. These headers typically can't be spoofed as they're added by the MTAs themselves. So they're often a reliable metric that we can use to perform our investigations. And you can almost think of it like a passport. As you travel across the world, well, you'll likely stop in various countries along the way. And at each stage in the process, well, you'll receive a check or a stamp as you pass through various checkpoints or layovers. An important point here is that the received headers are in reverse chronological order, meaning that the first header we see is the most recent or closest to the recipient. And at the bottom, the last received header we find in the email is the one closest to the sender or the originating server. Which means that if we want to figure out where an email actually came from, well, we should start from the bottom and move upwards. Depending on the route the email path took to get to our trusted infrastructure, we might need to look at a few of the earliest received headers. And as such, it's technically possible that the original sender of the email might have included spoofed headers to try and hide that they are the original sender of the message instead of just a waypoint along the way. As such, the only received headers that we should trust are the ones generated by our own trusted internal infrastructure or basically when the email is passed along to the MTAs that we trust. And so another way to put this is that the most important hops in an email's path across the internet is the first time that our trusted infrastructure, you could think of this as Microsoft or our own organization's MTA, interacts with the server that is sending the email. And we could go as far as to say that anything under this trusted received header cannot be trusted as the attacker could have modified or spoofed anything below this. In this case, we can see this first received header here which was supposedly sent by a proton mail address. But we can see it was received by the Outlook domain with the Microsoft SMTP server. And so we can be relatively sure that this was the original sender and this was the original sender's IP address. And if you recall, this is the same IP address that we saw in the X sender IP header. So now that we've identified some IP addresses that could be useful to us, we can perform some further investigation to obtain more data about the original sender. So to do this, we can use any free IP or domain lookup service out there or even the who is command in our terminal. And if you don't have who is installed, well, we can run pseudo app to install who is. Just need to put in your password there. And once it's installed, we can just run a who is and paste in that IP address. And if we scroll up, we can start to see some very useful information. Similarly, we can go to a site like who is.domaintools.com. And again, if we paste in that IP address and click on search, we're going to get the same results in the browser. So here we can see that the country that this IP address belongs to is in Switzerland. And the reverse DNS lookup or the resolved host points to mail-4140.protonmail.ch. And we can also see the ASN or the autonomous system number belongs to Protonag, which confirms that we're dealing with a Proton Mail email system that originally sent this email. And this obviously does not match up with Chase Bank, which is what the sender wanted us to believe by spoofing the sender address as chase.com. And of course, we want to ensure that the results of this check are well documented because they will come in handy during our analysis. And so doing this extra bit of reverse DNS research, we're able to attribute the original sending email server and confirm that this email did not in fact originate from anything related to Chase Bank. It's also worth noting that while we have some clever solutions to view these headers, like with Sublime Text, we also have some free tools available to us that can parse email headers in an easyto- read format. One of which is the message header analyzer tool which I'll have linked down below. And using this tool, we can paste in the headers from any email and get a nice and easy to read table that highlights some of the important headers for our analysis. And it's worth noting that all of the processing occurs client side. So we don't need to worry about any sensitive data from legitimate emails being collected. And this is an open source tool and the repository can be found here or linked down below. So we can just copy everything from our email and paste it into this header field here. And when we click analyze headers, well, we can immediately see that it gets parsed into this easier to read format. And so we can see the received headers here in this sort of table format indicating each hop along the way. We can also see the X sender IP highlighted here with our IP address. A second tool that we have access to is MX Toolbox, which is a super useful utility that can do a wide variety of things like reverse DNS lookups or message authentication checks and many more things. One of its options is the email header analyzer, which can be found in the link below. Like with the previous tool we just looked at, we can paste in an email's header here or source and click analyze header. And of course, this will parse them to present the headers in an easy to understand format. So we can see we have the received header relay here again with that IP address identified along with some email authentication checks which we'll get into shortly. Often times attackers won't even go as far as to bother with spoofing addresses. In these cases, it can be very quick to identify that it's an email with malicious intent and can expedite our investigation. For example, let's quickly look at sample 2.ml. And this is a real fishing email that I received in a honeypot mailbox. And in this example, we can clearly see that the sender is attempting to impersonate CIBC, which is a large Canadian bank. However, we just need to look at the from header to realize that this address is just a poor attempt at impersonating CIBC using some subdomains in the email address itself, like CIBC-banking. to make it look like it's affiliated. And interestingly, the domain of this mailbox, cib.com, is almost an anagram of CIBC, which makes me wonder if this was done on purpose to attempt to fool someone not paying close attention. However, if we want to look further, let's open this in Sublime Text. We can notice that the return path is set to a different email address, which raises our suspicion. Additionally, if we look at the received headers from the bottom up, we can notice that the originating mail server is affiliated with Comcast Business. And if we look at the X sender IP or continue looking through the email headers, we'll notice the IP address of 190.6.201.67. And so to be thorough and complete here, let's do a reverse DNS lookup again. So, if we paste in that IP address, we'll quickly find that the IP address is located in Honduras and is affiliated with a Honduran telecommunications company called Cable Color, which is not at all related to CIBC Bank. So, I think that was a good first look into email headers, and I'm going to cut it short here so we can talk about authentication headers specifically in the next lesson. Now, let's talk about email authentication headers because we've been hinting at them a few times so far. There are three major email authentication technologies out there. We have SPF, DKIM, and Demar. And using these protocols, we can check if a domain actually did send an email and essentially identify potential email spoofing. So, first we have SPF or the sender policy framework. And this is a mechanism that allows domain owners to specify which mail servers are authorized to send emails on behalf of their domain. And it works by publishing SPF records in the domain name systems or the DNS for a domain. And these SPF records contain a list of IP addresses or domain names of servers that are authorized to send emails for the domain. For example, we can check the SPF records for any domain manually using the NS lookup or dig command. So, for example, if I want to check the SPF records for showdown.io, well, I can just use the nsookup command, I can set the type to text because this is the format in which the SPF records are published. I can specify the domain, so shodden.io. And because this is going to give us all of the text records for the domain, well, I can pipe this to something like GP where I can just search for SPF records. And if we run that, we can see this string here, which is the SPF record itself. Now, before we jump into this, we can also do this with dig. So, if I run dig, I'm just going to search for text records for showdown.io. And again, I'm going to pipe this to Grep where I can search for SPF. And again, we get a very similar string here, which is the record that was published. So, let's look at this in more detail. So, first we have the version and this specifies the SPF version being used, which in this case and in most cases is going to be version one. Next, we have this IP address here along with this IP address. So, this specifies that these IP addresses are allowed to send email for the domain. We also have include an S spf.google.com. So, this includes the SPF record of this domain here, this spf.google.com when evaluating SPF for the Showdown domain. So, this allows Google's servers to send email on behalf of Showdown. So, this is basically saying include everything from this SPF record. And if we were to look at that SPF record, well, we can see everything that it's going to include. And lastly, here we have this dashall. And this specifies the policy for mail servers that don't match any of the previous mechanisms. And in this case, the dash all indicates a strict policy, meaning that emails from unauthorized senders should be rejected. And the other one you'll see is the tilda all. And this qualifier is the soft fail. And this suggests that the server should accept mail from IPs not explicitly listed in the SPF record, but it should treat them with suspicion. But the dash all that we can see here, this means a hard fail. So it specifies a strict policy in which emails from IPs not explicitly listed in this record should be rejected. It is the most secure option, but it can potentially result in legitimate emails being rejected if not configured properly. And so when an email is received, the recipient's email server is going to perform an SPF check by querying the DNS records of the sender's domain. If the IP address of the sending mail server matches any of the authorized IPs or domains listed in the SPF record, well, the email is going to pass that SPF check. However, if the IP address is not listed or is listed with a different domain, the email is going to fail the SPF check. And so you might be thinking that this doesn't actually verify whether a sender is legitimate or not. All it does is verify that the sender matches or is authorized by the domain specified in the emails from address. You'd be exactly right. If an attacker registers their own domain, maybe a lookalike domain, and sets up SPF records themselves, or uses a service like Gmail or Yahoo, well, the attacker is going to pass that SPF check with no issue. So it should never be looked at in a vacuum. This is why it's equally important for us to look into the sender's actual domain along with performing these authentication checks. So next we have DKIM which stands for domain keys identified mail and this is a method used to authenticate the origin of email messages. Its primary purpose is to allow a receiver to verify that an email message was indeed sent from the domain that it claims to be and also that the message content has not been tampered with during transit. And it does this using PKI or public key infrastructure. And so when an email is sent from a domain with DKIM enabled, the sending mail server is going to add a digital signature to the email header using a unique private key associated with that domain. The public key corresponding to the private key that is used is then published to the DNS record of the sending domain. And so upon receiving the email, the recipient's email server is going to retrieve the public key from the sender's DNS record and use it to verify the DKIM signature. If the signature is valid and the message content hasn't been tampered with, well, the email is considered authentic or passes the check. And again, it's crucial to note that DKIM alone doesn't evaluate the content of the email or the intent behind it. While it establishes the legitimacy of the domain, it doesn't assess whether the domain itself or the sender's intentions are malicious or not. For example, an attacker could still use a typo squatting attack to register a domain that looks similar and set up DKIM and SPF themselves to pass on their own lookalike domain. Or perhaps a legitimate mailbox was compromised. And of course, in this case, it's going to pass the DKIM checks if it's being sent from an actual mailbox. And lastly here we have Dmark or domain-based message authentication reporting and conformance. And DMARK works alongside SPF and DKIM to enhance the overall email authentication with additional reporting mechanisms. And so while SPF and DKIM individually authenticate emails by verifying the sender's domain and ensuring message integrity, Demar adds an extra layer of control and visibility for domain owners. And so Demar allows domain owners to specify policies regarding how their email should be handled if they fail SPF or DKIM checks. And these policies can include things like none, which instructs receiving mail servers to only report on email authentication results without taking any action. We also have quarantine, which directs suspicious emails to the recipient spam or quarantine folder. And we also have reject, which outright rejects email for failed authentication. And so it's important to note that demark policies only outline what actions receiving email servers should take when they encounter emails that fail demar checks, but they don't technically mandate or enforce compliance. And so ultimately the recipient's mail server administrators can choose whether or not to honor demark policies set by sending domains. And now that was uh quite a bit of theory here. So let's look at some email authentication headers in action. And so let's go to our fishing analysis folder. Open up the header analysis folder as well and go to sample3.l and we can see here we have an email that claims to be from namecheep renewals and namecheep is a domain registar and it looks like we're getting some sense of urgency here because we only have 7 days left to renew our domain. So let's open this up in sublime text. When we look at the received headers, we can identify when the email was routed from the sender mail server to our trusted Google mail server. And the IP address that we can identify here is 149.72.142.11. So this is the received header that tells us when the message left the sender's hands or who the sender claimed to be and into our trusted infrastructure, in this case, Google's mail servers. And so we can genuinely trust that this IP address relates to our sender because it can't be spoofed. You know, there was a genuine TCP connection that was made between these two servers. And this is the artifact from it, this received header. And so if we perform a lookup on this IP address, we can see that it actually returns as send grid, which is a very common email marketing solution, which could in theory be abused. But we can also see the reverse DNS of this mail server which does in fact return as namecheep.com. And so now that we know the original sender and mail server, let's look at the authentication checks. And so this is where we should focus our efforts particularly with our first check which will be SPF. We can see the header received SPF. This is a very important header for us because it provides information about whether the email server that received the message considers the sending server to be authorized to send emails on behalf of the purported sender domain. So what basically happened is that our email server or Google read the domain from the return path email header. In this case this mail service mailout one.namecheep.com it then check that domain's DNS records to ask something like hello mailout 1.namecheep.com namecheep.com. Do you have any SPF records published? And if so, do you send email from 149.72.142.11 because we just got an email from this domain that claimed to be from you. And so we can manually check the SPF records ourselves and mimic what Google did here on the back end. And so if you remember, we can use something like dig or nsookup to do this. So I'm just going to look for text records for mail servicemail.namecheep.com. It's actually email out one. I was uh scratching my head figuring out why that wasn't working. It's mail service email out one. And if you remember, this is going to return all the text records. So I want to GP out specifically for SPF. And we can see here we have the full SPF record that was published. And in this case, the SPF record is include sendgrid.net, which means that it includes itself and all of the records within sendrid.net within this SPF record. And if we look at all the records designated by sendgrid.net, well, we can see a number of IP address ranges published as authorized senders in their SPF record. And specifically, we can see this block here of 149.72.0.0 on this /16 subnet. And this is a cider block containing all of the IP addresses in the range of 149.72.0.0 all the way to 149.72.255. 255.255. And of course, the IP address of the original sender that we identified earlier and the one that our email server used to check SPF is within this range, meaning it passed the check. In summary, the email originated from this 022.mmail service.namecheep.com with this IP address, which is authorized to send emails for mail serviceout.namecheep.com. And the SPF record for this domain includes sendgrid.net, net indicating that emails may be sent through Sengid's infrastructure and the receiving email server in this case Google server verified this and allowed the email to pass through. So next let's look at DKIM and you can see we have a DKIM signature header here. Well actually we have two one for namecheep and one for send grid. Both signatures seem to be using the same body hash and including the same set of header fields but they will come from different domains and selectors. And this can indicate what we already confirmed, which is that the email was processed through multiple email systems, each applying its own DKIM signature. And since we're looking for integrity with DKIM, well, let's focus on the signature closest to the source or the namecheep one, and break down its components. So, first we have the version, and this is version one, which typically should always be one. Next here with this a field, well, this actually refers to the algorithm that was used to generate the signature. In this case, we have Shaw 256, which is what you'll typically see. But also be warned if you see a weaker algorithm like Shaw 1. It doesn't necessarily mean that it's a malicious email. It just means that a weaker algorithm was used to generate the hash, indicating a higher chance of hash collisions. But it's not really something to worry about. We also have this C equals relax/reaxed. And this refers to the canonicalization algorithm used for both the header fields, this first one, and the body of the message. So, DKIM uses this to ensure that the signed content like the headers and the body are consistent across email systems to prevent the signatures from being mismatched or failing due to whites space or formatting changes. And so, relaxed means that you know minor changes in the whites space and line breaks are permitted between the header and body which are accepted variations that still maintain the contents integrity. And we also have the domain here. So, namecheep.com and if we look down to s here, this is the selector. And so together the domain and the selector are used to locate the associated public key that email systems can use to verify the signature. So now that we know the domain and the selector we can actually manually check the public key ourselves through DNS. And so to do this the syntax will be the following. And again we can use nsookup or dig to do this. I'll use nsookup because we can also do this on Windows as well. And I'm going to put in that selector as the subdomain here. And typically the syntax here is going to be an underscore with domain key. And then we're going to put in the domain. So namecheep.com. And if we look this up, well, we get this response. We can see there is a canonical name set to this sendgrid.net domain. But we can also see the contents of the public key itself. And if we go back to our email, well, we also have a couple other fields. So we have BH here. And this is the body hash which was computed using that hashing algorithm and encoded in B 64. And under that we have the B field which is the DKIM signature itself which is calculated based on the header fields and the body hash itself. And now we don't have to verify this manually. Of course obviously our email system has done this automatically for us but we can also use several tools at our disposal to do this ourselves. Now instead of using NS lookup well we can do this lookup through MX Toolbox. Now if you remember we had the domain name which was namecheepief.com and we had the selector or S1 and if we do a DKIM lookup well we can get the same result. We can see the public key here along with the other details of that DKIM signature. And now if we go to the email header analyzer and we copy the contents of our email and paste it in we can analyze the header which will perform some DM checks for us. If we scroll down to dkimnamecheep.com with this S1 selector, well, this was the DKIM signature that we were analyzing manually. If we click on show here, we can see all of the checks that were performed. So, we can see that the DKIM record was found and that the record was valid. We can see that the public key was present, which of course we verified manually, but that the signature was also valid. We can see that the signature domain matched and there was alignment with the signature in the domain. And so alignment is when the DKIM signing domain matches the header from domain. In this case, it was namecheep.com. So it does check out. You'll notice that the body hash did not verify. And this is something you want to make note of because it means something in the contents of the email message were changed, obviously breaking integrity. However, in this case, it's actually expected here because for the course, I had to manually redact some identifiable information like the original recipient. So just trust that we don't need to worry about the body hash check for this example. So let's put all of this together using the authentication results header which we can see here. The authentication results header is used to convey the results of all these various authentication checks. And in our email it indicates that DKIM passed the check for both namecheep and send grid. In this case we can see that SPF passed as well. And lastly we can see the actual demark policy. In this case, we passed, but had we failed, well, it's set to reject, indicating that it would tell mail servers to reject this email if it did not pass. So, after all of the analysis we done, well, do you think this email was real or was it a fishing attempt? Well, if not obvious already, with all our checks, it was in fact a legitimate email. Now, I will stress again that these email authentication checks are not a silver bullet for determining the legitimacy of an email. They simply confirm that the email has passed through certain authentication protocols like SPF and DKIM. While passing these checks is a positive sign, it never guarantees that the email is completely safe or genuine. Right? So attackers have various methods to exploit loopholes in these authentication systems like for example registering a lookalike domain and setting up the infrastructure to pass these checks themselves or actually compromising a legitimate mailbox. or an attacker might leverage legitimate email services like Google or Yahoo, which will pass all of these checks. So, of course, while they're important, they should not be blindly trusted. Malicious emails can sometimes slip through these checks, and legitimate emails might also occasionally fail them, mostly due to configuration issues. And so, it's essential for us to conduct further analysis beyond just relying on authentication results. So we need to verify the domain and the sending IP address doing reverse lookups and seeing what email server is actually on the other end and also assessing the overall context of the email and carefully examining its content which we're going to do in the next lesson. Now that we've discussed header analysis, let's shift our focus to the substance of these emails, right? What language does the email employ? Are there any indicators of social engineering tactics? How does the email appear when it's viewed in the client? We can think of considerations like the content type, encoding or wording or even grammar and formatting. So to start, let's open our fishing analysis folder and let's head to the content analysis directory and open up sample 1. ML. So this is going to be the first email that we're looking at. And specifically, let's also open this up in Sublime Text. And so in a typical email file, the actual body of the email consists of the MIME or the multi-purpose internet mail extension parts. And so if we look at this header here, we can see the MIME version of 1.0. And MIME allows emails to contain different types of content like plain text or HTML or images and attachments. Each part of an email is typically separated by a boundary similar to this one. So again, some of these headers we have the mime version and so this indicates the version of mine that's being used. We also have the content type. So this header will specify the type of content in the email body. So it can be plain text like we see here or it could be text/ HTML for HTML content. And there are many other possibilities. And next we have the content transfer encoding header. And this header specifies how the content is encoded for transmission. So common ones you'll see are 7 bit or 8 bit or even base 64 which we looked at earlier or quoted printable and of course in our example it's 7 bit and this means that no encoding is applied and we talked about the boundary and so each mime part is separated by a generated boundary string and so this boundary is used to differentiate and distinguish different parts of the email body and so the presence of two boundary strings here indicates that the email contains two parts and this is a common practice in mime encoded emails. to provide an alternate representation of the same content. In this case, we don't have any plain text content. All of it is under this HTML here. And we can see the text HTML under the content type indicating that this is going to be HTML rendered content. Just as a quick aside, this is a completely separate email, but you can see if we scroll down to the content section, we have two different types of content here. The first version of the email as signified by the content type header is a plain text email. And we can see here this email is just written in plain text. If we scroll down, we can see a second content type partitioned by the content boundary. And in this case, it is an HTML version of the same email. And if we were to open this in our email client, well, we can obviously see the HTML version of the email signified by the images and the different styling here. But if we go up to the view tab and go down to message body, well, we can change it from original HTML to something like plain text. And now we're visually seeing that plain text version of the email. Now, let's return to the email in the client. And we can see some oddities right off the bat that might provide red flags that this isn't a legitimate email. Well, first off, the email is claiming to be from Trust Wallet, a cryptocurrency trading platform. At first glance, I didn't know what Trust Wallet was. But a simple Google search showed me that the organization that the email claims to be from is somewhat legitimate. However, the first thing I notice is that there is a discrepancy between how the company name is spelled in the email versus how the company name is actually spelled. So, we can see in the email, well, we don't have a space between trust and wallet. It's all one word, but the actual company is two words, trust and wallet. And there are also a couple of random grammar and spelling oddities in the email, such as the greeting. So, we can see hi dear semicolon customer. This appears to be a failed attempt at writing a generic greeting since it sounds awkward and contains awkward punctuation. Sometimes you'll see fishing emails that can actually parse and decipher a mailbox's associated name such as Andrew or Bob or Emily. But in this case, less configuration was done on the attacker end to just give a generic customer greeting. The first line of the email here also indicates a potential attempt at inducing a sense of urgency, claiming that we have an unverified account that will be suspended if we don't action the email. And of course, this isn't always a case closed kind of indicator, but seeing these types of social engineering tactics come into play should raise our suspicion and warrant further investigation. You'll often see this done with expiring accounts or claiming accounts will be suspended because in many cases, money and bank details are involved like with banks and cryptocurrency exchanges. Well, victims might feel a heightened sense of urgency and quite easily click on malicious links. And so, let's take a look at sample two. And again, this also claims to be from Trust Wallet. And we can obviously go into the headers and almost immediately identify this as a spoofing or impersonation attempt, but let's just focus on the content. This time, they seem to have typed the Trust Wallet name correctly, but we're still getting a generic greeting with dear customer, and a lot of poor grammar. For example, we can see the possessive accent here next to NFTTS, which grammatically shouldn't be there as it's indicating a plural. Lastly, down here, the word assistant is spelled incorrectly, indicating whoever wrote this email might not have English as a first language. And surprisingly, this is a very common occurrence. You know, you don't have to be an English major, but being able to spot grammatical or spelling errors can quickly raise suspicion that an email did not come from a professional source. But on the other side, with things like AI and options like chat GPT are becoming so readily available, well, attackers from all around the world can quickly generate legitimate sounding copy for emails, which is why this alone can't be our only barometer. So, next, let's take a look at sample 3. And in this case, we'll find a genuinely convincing looking body resembling an Amazon account suspension notice. And it uses all the correct formatting and logos and fonts. They likely copied this from a legitimate Amazon email. And so you can imagine that someone who might have recently ordered something on Amazon, which of course is quite common these days, could receive this email and jump to conclusions out of fear and manipulation of authority. And in this case, the content of this fish was done so well that we can't just rely on content inspection alone. And of course, we never should. And so we'll need to look at other methods of analysis like header analysis and URL inspection, which we'll get to in the next section. And now we talked a bit about encoding before. B 64 encoding is a method used to encode binary data into ASKY characters, making it suitable for transmission over textbased channels like email. And so B 64 is very common within emails because it converts binary data into a string of asky characters. And so B 64 encoding is often legitimately used within email messages for things like presenting non-asky characters or email attachments like images or documents. But it can also be used to offiscate the email's content and potentially evade detection by very weak email filters. Either way, we should be familiar with recognizing and decoding it to reveal the true email content. For example, let's open up sample 4. And let's also open it up in Sublime Text. So, if we scroll down to the content of this email, and we can also see it from the preview window here, we have a long block of B 64 content. And how do I know it's B 64 data? Well, partly due to experience and knowing what base 64 strings look like. And admittedly, there's some common indicators like this one or two equal signs at the end which indicate padding characters. But of course, we can also just scroll up and realize that the content transfer encoding here is set to base 64. And I believe in a previous lesson we looked at doing this through the terminal. But we can also use a tool like Cybersh to decode this for us. So I'm just going to copy the entire string here. And I'm going to open up Cybersh. And in this input window here, we can just paste in the contents. And if we go under operations, well, we can see it already. If we do from B 64, you can see that this operation will decode data from an ASKI B 64 string back into its raw format. So if we drag this over to our recipe and let it go, well, we can see in our output that it was successfully decoded into HTML text. And so if we look at this, this is the actual HTML and CSS markup that made up our email. So next, let's cover another encoding mechanism called HTML entity encoding, where in reality, this is really just a sequence of characters to represent specific HTML characters. And so HTML uses entities to display characters that are reserved for HTML syntax or characters that have specialized meanings like the angled brackets here, the less than and greater signs or things like amperands and non-breing spaces. So for example, if we go back into Cybersh and if we just put an and symbol here and if we go under operations and look for we can just do a search for HTML entity. And if we drag over to HTML entity, well, this is going to convert characters into those HTML entities. And if we drag this over, well, we can see our and symbol here turned into this and AMP with a semicolon at the end. And for example, if I were to check off this convert all characters, well, this is going to basically convert everything I type into HTML entities. If I just type in test, for example, well, we can see a number of HTML entities. This one refers to the letter T. This one refers to the letter E and so on. And so attackers often employ various techniques to bypass spam filters. And the use of HTML entities is one such method. And you can likely see how HTML entities can be leveraged. For example, suppose we have a spam filter in place to reject or quarantine any emails that include the phrase Bitcoin. And bear with me in this scenario. Maybe our organization has nothing to do with Bitcoin and we've been seeing an uptick in cryptocurrency related scams. In this case, an attacker could just insert one of these entity characters to potentially bypass the spam filter. And I'll say any good quality filters will be able to decode this and perform static analysis to catch this evasion attempt. Lastly, let's take a quick look at URL encoding. And URL encoding is a method used to convert characters into a format that can be transmitted over the internet. Again, this is often used for legitimate purposes, but an attacker may attempt to encode URLs to bypass some weaker spam filters. And URL encoding works by replacing non-alpha numeric characters with a percent sign followed by a two-digit hexadimal value that represents the character in the ASI character set. For example, let's paste in the cybersh URL into the input. And if we do a quick search for URL, well, we should see URL encode as an option right here. And this is going to encode potentially problematic characters into that percent encoding. So, if we drag this over to the recipe and click on encode all special characters, well, we can see a number of those characters like the colon and the backslashes have been transformed into that percent encoding. So, if we open up sample email 5 in sublime text and scroll down to the body content and if we hit F to do a search, we can search for percent to E. And we can see a long string of text here that is both URL encoded and also HTML entity encoded. And of course we can decode this using Cybersh. So if I just find where it ends based on the quotation here and go all the way to where this URL starts based on the first quotation, I can just copy this. And interestingly enough, if we scroll up here to the content transfer encoding, we can also see that this content is encoded with the quoted printable. And so basically that's three layers of encoding we have here in that URL. So, let's head back over to Cybersh and paste in that URL. And we can see it doesn't really look like a proper URL because it's been encoded using that quotable. So, first let's look up quoted printable and we can select the from quoted printable option. Let's drag that over to a recipe and we can see our URL is starting to look a little bit better. But remember, we also have HTML entity encoding. So, let's look up that as well. If we scroll down to from HTML entity again, we can drag that into our recipe and we can see that our URL was cleaned up a little bit. And lastly, let's look up URL and go down to URL decode and drag that over. And we can finally get to our full URL without any of that encoding. And so now that we have the URL decoded, we can now pass it over to some tools to conduct URL analysis. And speaking of URL analysis, well, let's get into that in the next lesson. Now, arguably the most important thing contained in the content of an email message is going to be the URLs, which is not something we've covered yet. So, let's dive into URL inspection and analysis within this lesson. So, let's first quickly go over the anatomy of a typical fishing URL because we can learn to identify some indicators that might heighten our suspicion as we go about analyzing these links. So in a standard URL like the one you can see on screen, we often have some or all of these components. So first we have the protocol and this indicates the communication protocol to be used for accessing the resource and describes the way in which browsers should retrieve the information. So common protocols you'll see might be HTTP or hypertext transfer protocol or of course HTTPS. But there can also be protocols like FTP here as well. And next you might have a subdomain. And so a subdomain is like a subdivision of the domain that can be used to organize or distinguish different sections or zones of a website. And so we can think of mail.google.com or drive.google.com. And in this case we have the academy subdomain of the TCM domain. And so next of course we have the domain name itself. And the domain name consists of the second level domain which is the name of the website in this case TCM sec and the top level domain which specifies the type of website that it's going to be. And so you might see things like.com or.net or.edu or.gov or even country specific names like or.ca.is. And the combination of this tople domain and the second level domain is the only part that is unique in the URL. And so this is very important because attackers can spoof subdomains or registered identical domains under different top level domains, right? But the combination between the second and top level domain cannot be copied. And so when we put all of this together, this becomes the host name. And this is made up of the domain name as well as any subdomains. And so next we have a subdirectory. And this is a directory or folder within the website's file structure or a defined route on the server side that is used to organize content. In this example, we have a subdirectory called courses which holds files for various courses hosted on the site. And speaking of files, well, this is the specific file or resource being accessed on the server. So, it could be an actual file with an extension like a.php or just a route that points to a file in more modern applications and might not contain a file extension. And together, we refer to the file being accessed along with any subdirectories as the path or the entire location of this resource. And optionally, you might see things like parameters. And so parameters in a URL are additional pieces of information that are appended to the end of the URL after the question mark symbol. And these parameters are often used to provide specific instructions or data to the server when you're requesting a resource. And they're typically structured in these key value pairs, right? We have t= 129. And so we have the name of the key along with its corresponding value separated by an equal sign. And of course, we can have multiple parameters in a URL by separating them with the amperand. In this case, this is just a madeup example, but maybe the t key refers to a timestamp of a specific video that you're watching on the academy. In this case, the value might refer to 129 seconds. So, when you navigate to this URL, the server knows to retrieve or display the video starting from the 129th second. And YouTube actually does this exact thing. Now, this was a clean example of a URL, of course, but let's look at some actual recent fishing URLs that I pulled from a malware database. And we can see how they're constructed. And in this case, the first thing that jumps out is the absence of the HTTPS protocol in the URL. This indicates that the connection to the website is not secure. And most often legitimate login pages, especially those with sensitive information like email credentials, will use HTTPS and automatically upgrade non-scure connections to encrypt data transmission. And of course, there are still legacy sites and bad configurations out there, but it should be one of those indicators that makes us suspicious. And so next, we actually have an attempt at subdomain spoofing, which we can see here. The subdomain apple-lo suggests that this URL is associated with Apple's login system. However, if we look at the base domain, DNSD.net, well, this of course does not match Apple's official domain. We also have an somewhat unusual domain extension. And this is not a huge indicator, but we can see the net here is a little odd because it's typically not a tople domain that Apple would use. And so, next here we have an odd subdirectory. And to be honest, I'm not sure what this means. And you might see odd generated UIDs or strings or specific routes in certain applications, but in this case, it just seems a little odd. And if I were to take a guess, the attacker probably uses this base domain to host a variety of different fishing campaigns and likely titles them with unique identifiers like this one. And if we jump to the end here, we can see a suspicious parameter. And this parameter seems to be collecting email addresses. And I actually redacted the original email from the URL. But in the case of this actual email, well, the victim who received it had their email prefilled into the URL. And this is actually something you'll see quite commonly and is one of those red flag indicators that should immediately make you suspicious of a URL. Like fishing websites will often request personal information like email addresses and passwords. And to make them seem more credible, attackers might try to prefill certain fields in the URL or web page to make it look like the website is real and it like saved your information from last time, right? Like email addresses. And they can do this very easily by appending it in URL parameters. So let's look at another one here. In this case, we have another example of subdomain spoofing. The subdomain MetaMask-restoration-sport. Well, this suggests that there's a connection here to MetaMask, which is a popular cryptocurrency website. However, if we look at the actual base domain, this webflow.io, well, it does not correspond obviously to MetaMask in any way. In this case, we have the abuse of a legitimate service. And so, Web Flow is actually a custom website builder. And attackers commonly use services like this or services like Wix to quickly spin up a hosted web page that already has the trust of a legitimate service. And speaking of that, here is another example of subdomain spoofing and the use of a legitimate service. And quite honestly, I see the wicksite.com/my site string so often that in my opinion, it's probably a good idea to just block any email containing this string. And so, can you see what's wrong with this URL? Well, in this case, we have a form of typo squatting where the letter R was omitted to create a lookalike domain. And so, a user not paying close attention could fall for something like this very easily if the web page itself closely resembled Microsoft. Now, how about this one? Can you see any red flags? Well, we have some potentially suspicious subdomains and also this query parameter is a little hard to understand. But actually in this case this is a legitimate URL and I wanted to include this to show that legitimate sites can have a number of subdomains especially in the login process. In this case we have connect.secure but we can see that the base domain or the full domain is wellsfargo.com which is the legitimate site for the bank. And legitimate sites can also use weird or vague parameters to control different aspects of the page or rendering. In this case we have origin equals co. And in this case, I'm not actually sure, but it could be indicating that the login request is coming from the consumer online banking or the COB platform. And of course, this is just a guess. And we don't actually have to go around trying to deconstruct every parameter we find, but it's definitely something to look out for. And now, what about this one? It looks very similar, but do you see it? Well, the S was omitted to read Well Fargo. Now, of course, this is not a real example. I just modified the one from before. But in this case, in our example, the attacker would have set up the web page and the subdomains in such a way to mimic the original almost exactly. This is why it's so important to understand that the only true unique portion of a URL is the combination of the domain name and the top level domain. Now, lastly, what about this one? And it's identical to the ones before, but in this case, the top level domain has been changed. Now, remember the second level domain or Wells Fargo and the tople domain.com cannot be spoofed. they're completely unique. But in this case, an attacker would have registered a very similar domain with a tople domain that looks like.com, but in this case isn't. And again, this isn't a real example. And Wells Fargo might have actually purchased the Docam variant of the domain proactively to prevent this kind of typo squatting. Okay, let's get back to business. So the first step in URL analysis is of course extracting the URLs from the email content. And this can either be done manually or through a number of different automated tools or scripts. So the first method we'll cover is not something I'd typically recommend, but still something that we can demonstrate. So first, let's navigate to the URL analysis folder within the fishing analysis section, and let's open up sample 1. ML. And you'll probably recognize this chasebank fish from the header analysis section. So now that we have the email opened up in our client, we can actually use our client itself to hover over and view URLs or hyperlinks within an email. So for example, if we move our mouse over to the reactivate your account link, well, we can see in the bottom of our client where that URL leads to. And for any links or URLs that we find, we can rightclick on the link itself and click to copy the link location manually. And the issue with this method is that when we're potentially dealing with malicious URLs. So you can imagine that a simple misclick like if you accidentally hit the left mouse button instead of the right, well, it means that we could accidentally end up visiting the page. And also this method relies on visual inspection. And so it's very easy for us to miss a hyperlink by not seeing it in the email. Or even some CSS styles could be implemented so that URLs aren't colored blue or not underlined or not in a button like this, which we're used to seeing. You know, we could even be dealing with an image that's clickable that we won't really notice unless we hover our mouse over every word. And so, this leads us to some more robust methods. And as you're familiar by now, well, we've been opening up emails inside of Sublime Text. We could essentially use any text editor, even like Notepad on Windows, but Sublime Text is a useful and also a personal choice. And so once we open up sample one in Sublime Text, we can use the native search functionality to find any instances of URLs in the file. So this is going to require a bit of logical thinking, but if we hit Ctrl+F, we can open up this search pane. And then we can search for specific strings like HTTP. And we're not always going to get a URL with this method because sometimes HTTP is a string that's included in the body of the content or maybe somewhere in the headers. But if we keep scrolling around, we can see we have four matches here in total. And the first one here, we get a URL. And the next one here, we also get that URL. And this specifically is the reactivate your account button that we were looking at in the rendered content. Alternatively, we can search for things like the opening bracket in HTML. And then search for the A which is an anchor tag. And in HTML, an anchor tag like this is used for hyperlinks. And so again, we can immediately find this reactivate your account link. And of course, the advantages of this method are that we have no risk of accidentally clicking on a link. And also, we won't miss any findings as long as we use the right search strings. As another method, we can also return to the ever useful Cybersheef to automatically extract URLs from an email file. And so, let's navigate back to Cybersh. And in this case, we can either paste the entire contents of the email message or alternatively, we can click on this open file as input button. And from here we can navigate through our explorer window to find the specific file that we want to upload. And you can see here once doing that we've uploaded the entire file into the input. Now if you remember this specific email was encoded with that quoted printable encoding. And in this type of encoding well our URL is actually being split into multiple lines. Meaning that if we were to just try to extract URLs the normal way, well we wouldn't be able to do that. So if you remember what we need to do is to first decode this from that quoted printable encoding and so we can just search for quote here and we can select the from quoted printable and drag it into our recipe and from here we can then search for URL and what we're looking for here is extract URLs and what this is going to do is as the title suggests extract any URLs from the text and you can see here once we drag that into a recipe we are getting those two URLs that we identified earlier. And lastly, while we're here, and this is something we'll cover shortly, but we can use Cyerechef to defang the URLs. And to defang a URL means to modify it in such a way that it no longer functions as a clickable hyperlink. And this is often done for security purposes, especially in context where we might not want to click on a malicious link. Now you can imagine that as we document these specific URLs either in our report or in a ticket. Well, when we paste them into our ticketing system, these URLs can sometimes be automatically converted into a clickable hyperlink. And obviously, as we are dealing with potentially malicious URLs here, well, we want a way to prevent them from being automatically turned into links. And so by adding the defang URL option, which we can simply search defang, we can drag over the defang URL. And you can see these hyperlinks were changed slightly. Instead of the protocol as HTTPS, it added these two X's here to make it an invalid protocol. Additionally, certain things like the dots separating the subdomains or the col/ slash to indicate the protocol have been squared out in these brackets. These defanged URLs are now safe for us to document and it is of course best practice to do so. And lastly, there are of course other ways to do this. And I want to demonstrate a tool that I wrote specifically for this that can save us a lot of manual work. And this is the email IC extractor. And it's definitely not the only kind of script out there for this purpose. But it is a Python script that is designed to aid in email forensics and analysis by extracting various components from the email files. So it will extract things like the IP addresses, the URLs, and even headers and attachment information. And it will all do this in this defanged format. So, if you're curious, we can open it up here by clicking on ei.py and click on the raw view. We could clone the entire repository, but we really only need the script itself. And back in our terminal, I'm going to back out into the tools directory. And then I'm just going to w get that URL to copy the Python file. And now all we need to do is run the Python script. And we can do that with Python 3 and then provide the name of the script. And you can see we're getting the usage information here. So, it wants us to provide a file path to the email file that we want to investigate. So, in this case, we can back out of the tools folder, go into our URL analysis folder, and then we can select sample 1. ML. And when we hit the enter key here, it's going to run those automated checks for us. And so, you can see if I scroll up, we extracted several things like the IP addresses, and these were specifically from the email headers if you remember correctly. And this script even introduces some enrichment capabilities to do that IP lookup. So we can see the AS number and we can see the location of this IP address. In this case, we don't get the information for the first IP address because if you recall, this is a private IP address. But if we scroll down, we can see the extracted URL section. And much like with Cybersh, we getting that same output in defanged format. We can also see some common and useful headers for us like the authentication results, the from the date, the message ID, all of these things that we typically want to document. And of course, this is a very quick and easy way to do it. But of course, it's not foolproof. So that's why I wanted to go through manually extracting headers first so we understand the reasons why and the methodology before we start relying on tools like this. And now once we've extracted the URLs from our suspicious email, well, we're of course going to want to analyze them and perform reputation checks to help us determine if they're malicious or not. And of course, we have plenty of tools at our disposal to perform these checks, which we're going to cover in this lesson. And again, it's important to note that these tools are not foolproof. And what I mean is we can't just blindly trust these tools to give us a verdict. We have to use critical thinking skills and make our own judgment. And so just because a URL is not identified as malicious by our tooling, well, it does not mean that it's safe. It just means that the URL in question might not have been submitted and reported before. And now a blessing and a curse here is that malicious websites often get taken down quickly. Either through individuals and organizations investigating them and reporting these websites or the ISPs themselves and the registars being made aware through alerts and taking them down or even services like Google Safe Browsing and Microsoft Smart Screen updating their signatures to block these sites. And so because of this, some of the URLs in the emails here might not be live when you're watching this lesson. And so to get some live and recent URL samples, I'm going to be using Fish Tank, which I briefly showcased before. And essentially, Fish Tank is a database where researchers can report malicious fishing URLs for community review and categorization. So let's start looking at a tool that is self-proclaimed as a screenshot as a service tool. So, you might have wondered if there's a way for us to get a visual representation of what a specific website or URL looks like without us having to actually navigate to it and potentially expose ourselves to a malicious site. Well, we can use a tool called URL to PNG for this. And I'll have this link down below. And by inputting a suspicious URL into this site, we can generate a snapshot of its current appearance, allowing us to assess if it's legitimate based on visual cues like the design and content and layout. Of course, this isn't foolproof, but it's a great resource for us to be able to grab a screenshot of a website that we can put in our reports or tickets. And of course, just like I mentioned, this does not provide any insight into the underlying safety or security of the website. So, even if a site appears benign in a screenshot, well, it could of course still be malicious. And so, as such, we need to complement this tool with other analysis methods that we're going to cover. So, I'm going to try to find a live link here that we can analyze. And specifically, I can see this one near the bottom. this sp5618.com/lo because it says /lo. Well, this is particularly interesting for me. This is most likely a credential capture page. So, I'm going to copy this link and head back over to URL to png. From here, I'll just scroll down to where we find this URL bar. And I can just paste in our URL here and click on I'm not a robot. And from here, I just click on the green button here to start the scan. And you can see almost immediately we're greeted with what looks like some sort of credential capture page. Specifically, it looks to be impersonating the Shopppee service. And if we look up Shopppee, well, it appears to be some sort of e-commerce platform based in Southeast Asia. And of course, the actual domain here is shopppee.com and not this SP5618. So, it's clear that we most likely found a credential capture page here. And so, this leads us to urlcan.io. And this is an online sandboxing tool that allows us to analyze and inspect the behavior of URLs in a controlled environment. So, I'm going to head over to URLcan.io. And we can see a bunch of recent scans here that other people have performed. And one of the key advantages to URL scan is that its ability to provide detailed reports on the analyzed URL's behavior. And these reports can then include information about the reputation score of the domain or verdicts based on previous reports and scanning or even the underlying web technologies that make up the site. And similar to URL to PNG, we can often get a screenshot of the site as well. So, it really does it all. So, one thing to note here is we want to go under options and click on a private scan. If we don't, well, our scan result and report is going to be made public, which you can see with all these results here. And sometimes you might be dealing with a potentially sensitive URL that might contain some real data, right? And so to preserve some of our privacy, we're going to click on this private scan here. And then we're just going to paste in our URL. So, let's use the same one from before and run a private scan. And now the report is finished. We can immediately see some interesting things. First, it looks like it did manage to get that screenshot for us. And we're seeing the same credential capture login page. But we also get a ton of more information. Specifically, we can see the IP address related to this domain or this website. And specifically, if we look at the summary here, we can see that the website contacts two different IPs at runtime. We can see the main IP of the website is this and it's located in Singapore. We can even see who it belongs to or the ISP. And some even more interesting information is under this live information tab. Specifically, we can see that the Google safe browsing service already has identified this website as malicious. And very interestingly, we can see when the domain was created on May 10th of 2024, which at the time of this recording was yesterday, which is almost a silver bullet for us because honestly, if a domain was registered yesterday or even in the last 30 days, most likely it is some sort of fishing attempt. And often what organizations will do will block any email sent by or containing a URL that has a domain created in the last 30 days just because this is so prevalent. And so another tool in our arsenal is going to be Virus Total. And Virus Total, which we're going to look at so many times within this course, is an immensely popular online service that can aggregate multiple antivirus engines and other security products or tools to scan files or URLs or even just hashes for potential threats. And so what we can do here is go under the URL tab and paste in that URL. We'll use the same one we've been using. And by submitting a URL to Virus Total, well, we can leverage its extensive database of signatures to assess the safety of the link. And also, Virus Total will allow us to view the historical data and also community feedback about a URL. And by doing this, we can gauge its reputation over time. So, I pasted in that URL, and I'm just going to hit the enter key to run our scan. And we can see almost immediately two of 92 security vendors flag this URL as malicious. Most likely, just because it's so new, I expect to see this number grow as time goes on. But we can see one of the vendors here flagged it as fishing. And if we go under the details tab, we can again see some interesting information. We can see the final URL in the case of any redirects. We can see the serving IP address. We can even get a hash in Shaw 256 of the body of the HTTP response that was sent back from the server. We can get all of the response headers as well. And so again, Virus Total is going to be a very useful tool for us, and we're definitely going to return to it once we get to the file attachment analysis stage. Now, again, if you recall, we did not have an option to do a private scan here. So, of course, you want to be very careful when submitting sensitive data, specifically with URL parameters into Virus Total. For example, maybe if this URL had a parameter like email equals and then some sort of internal email address at our company name. Well, it would typically be best practice to remove this parameter from the URL because we don't want it to be scanned and logged on virus total. And now before we move on, there are a couple of other useful tools that I'll cover. So, URL void is another such tool that can help us detect potentially malicious websites and also perform some checks on the website's domain or URL reputation. And this service is going to run our URL through over 30 block list engines and also website reputation services to generate a verdict for us. So again, let's paste in this same URL we've been using and hit scan website. Interestingly enough, we did not get any detections this time. However, we get a number of useful information that we're used to seeing. But in this case, the website was likely too new to be captured by any of these detection engines. So, of course, this is a good example of why we don't just blindly trust one tool because if we were to only use URLvoid, well, maybe we would blindly assume that the site is safe. Now, what if we wanted to get the actual contents of the web page? You know, we've gotten a screenshot before, but what about the actual markup and the HTTP response? Well, we can use a tool like W browser to simulate a browser and get the response for us. So, I'm going to paste in the URL and hit get here. And in our response here, we can see general info, but if we scroll down to headers, we can get all of the response headers. And interestingly, if we go to the body, we can see the entire body of the response. And interestingly, we can see some inline script tags with this JavaScript here. So in cases where we wanted to return the actual markup or response of the body, well we can use a tool like wannab browser. We also talked before about shortened URLs and how attackers can use services like bit.ly or tiny URL to shorten and offiscate their malicious URLs to get around detection. Well, fortunately we can also use a tool like wannab browser to detonate that shortened URL and also follow any automatic redirects to arrive at the final true website. Now you might remember from a previous lesson I set up this bit.ly URL to /totally amazing website which in turn redirects to TCM security. And so if I paste in that URL here and hit get one browser is going to simulate a browser and follow any redirects. And if we look under the headers we can see that we got a 301 response at first. And if we look under the location header we can see that we were redirected to tcm-sec.com. And the second response here the 200 is from tcmssec.com. In the previous lesson, we demonstrated unshorten it to do this similar thing. So, let's demonstrate that again. And you can see the destination URL was in fact tcm-sec.com. And lastly, there might be cases where we don't get any solid results using the above methods. In this case, we can turn to some open source malicious website exchanges like fish tank, which allow researchers to submit suspected fishing emails to verify and analyze submissions. So, for example, we can do a search for that same sp5618.com website and click on is it a fish. And when we click on that, we can see the previous submission. So, while this hasn't been assigned a verdict yet, we know from our analysis that it most likely is a credential capture page. Similarly, URL house is a collection of malicious URLs submitted by researchers and automated scanners. When we view the database, we can see when a specific URL was added, the URL itself, as well as its status, like is it still up or has it been taken down, and we can also get some tags like what kind of fishing or credential harvester is hosted, as well as who reported it. And lastly, we can use Google Safe Browsing to check the status of a specific domain. If you recall, the domain that we were looking at was apparently flagged by Google Safe Browsing. So if we were to check the status here and click search, well you can see that this site is unsafe. And if we were to attempt to visit this in a Google browser, well, we would receive a similar warning. I'll also mention that it's very important for us to also do a scan of the base domain. And what I mean by that is suppose we identify a URL that has multiple subdomains attached to it or maybe for instance we have a number of subdirectories in our URL or various query parameters. Well, when we want to understand the extent of the attack and the scope, well, it will be just as important for us to understand what the base domain of the URL is hosting as well, we might be able to determine if the fishing attempt is isolated or if it's part of a larger campaign or if the attacker is attempting to use a legitimate service to conduct their fishing operations. Or perhaps the base domain itself is an actual legitimate website that the attacker managed to compromise and started to host malicious subdirectories and files on the website itself. Ensuring that we scan both our URL as well as the base domain will ensure a more thorough response and it's just something that we always want to document as well. And now you might come across URLs that actually come from legitimate services like Google or Dropbox. In these cases, of course, the URLs and the email itself can't be immediately written off as clean. Remember, the technique that attackers often use is to host malicious websites or documents using legitimate services to get around spam filters and security analysts. Take for example this Google Docs URL. Well, this is going to come back clean on all of our checks because it's affiliated with the legitimate Google service. And so, we'll need to dive deeper into the contents of the URL and what's actually being hosted on Google Drive to continue our investigation. And you can see here when we submit this to URL scan, well, it's coming back as no verdict. We're not getting any malicious classification here. When we look at the summary, well, we can see this is a legitimate Google URL that belongs to Google US. And we can see the main domain is in fact docs.google.com. And we can see all the IP addresses that were contacted do in fact belong to Google. But interestingly, we can see this screenshot here. And of course, like we looked at before, this is another one of those images that is attempting to impersonate an Amazon security alert. And I'm sure if we click on continue verification here, well, it would lead to a malicious website. But sometimes you might get a Google Drive link. In that case, you need to get a copy of the file hosted on Google Drive and then perform attachment analysis, which we'll get into in the next section. Now, at this point, if you still haven't been able to make a determination either way, even after all of these tools and services, it might be time to start looking at and setting up a secure virtual machine to sandbox the link and do some manual inspection and analysis. But remember, it's always best to air on the side of caution. If we still have suspicions at this stage, well, it's often best to assume it's malicious. And we can also leverage our additional analysis that we should have already done at this stage. For example, if we can already determine the original sender was fishy during our header and content analysis, well, it's likely that this URL can't be trusted either. Now, alternatively, we could use a tool or a service like Joe Sandbox, which if we use the free or basic version, it allows us to run a maximum of 15 analyses per month. In many of the socks I worked in, we typically invested in a tool like this that allows multiple analysts to run many more scans per day and it can be quite useful in expediting the triage process. And we're going to get more into Joe Sandbox later on and specifically use it for attachment and malware analysis. But just note that it can also be used to browse and dynamically detonate URLs. And so lastly, just remember that tools are always evolving. There are always going to be new tools and new updates to tools. So we need to understand the methodology first. And this methodology is that we need to collect artifacts in the form of URLs and check their reputation against known sources as well as using our own analysis to determine if they're safe to open. And so in the next video we're going to get into email attachment analysis which is going to have a similar methodology but we're going to use some additional tools. So far we haven't dealt with any emails that contain attachments. So let's change that and start demonstrating how we can safely analyze email attachments. And so email attachments can come in various forms. They can range from things like actual innocent, benign documents to potentially harmful files like executables or malicious macros and scripts. And now a word of caution is that anytime we're dealing with analyzing potentially malicious files, well, we need to do so in a secure and controlled environment. And we have many tools at our disposal, which we'll cover that allow us to abstract any potential dangers and analyze files for us. But in most cases, we don't even need to look at or run the file to perform a quick analysis and perform reputation checks. And that can be done through file hashes, which we're going to focus on in this lesson. So, as we mentioned in the fundamental section, file hashes and hashes in general play a crucial role in cyber security and file integrity verification. Essentially, a hash is a unique fingerprint generated from the content of a file. It's a fixed length string of characters that's typically represented in hexadeimal format. And so even a minor change in a file's content will result in a wildly different hash value. So what that means is that if a specific malicious file or document was found in an attachment we're analyzing, we can potentially look up the unique file hash or fingerprint to see if it has been reported elsewhere or automatically picked up by a number of different antivirus and threat intelligence platforms. And so common algorithms that we use to generate file hashes are things like MD5 and Shaw 1 and most specifically Shaw 256. And while in practice it's typically recommended to use a stronger hash value like Shaw 256 due to things like hash collisions, well, it's not as important when we're dealing with collecting a files hash for reputation checks. And it's also very simple to just quickly collect all three. Now, how you actually obtain the attachment for analysis entirely depends on your organization's workflow and tooling and procedures. For example, if you're dealing with a fishing report through an alert in a ticketing system, well, there might be some workflows and data enrichment capabilities in place to extract the attachment from the email or even do things like retrieve its file hash for you. Otherwise, you might need to manually extract the attachment for analysis. And most email clients allow you to save attachments to your local system. But of course, ensure that you handle the attachment with caution to prevent any accidental execution. And so our goal is to save the attachment to our computer and of course not open or execute the file inadvertently. So just as a quick example, let's go to the fishing analysis section and go under the attachment analysis directory. Let's open up sample one. And we can see we have a suspicious email here requesting a wire transfer. And specifically, if we scroll down, you can see there is an attachment associated with this email. And so what we can do specifically in Thunderbird is rightclick on the attachment itself and we can hit save as. And so we just need to select where we want to save this. I'm just going to put it right in the attachment analysis folder. And I'm going to hit save. So you can see here that we successfully extracted the attachment from the email and saved it into our directory. In a Microsoft environment, specifically through using Outlook on the web, we can simply click on the action icon next to an attachment and click on download. And of course, this will download the file to our disk. And within a Googlebased environment, it's quite honestly as simple as hovering over the attachment and clicking on download. And this is going to download the file to our disk. Next, I'll showcase an additional script that will allow us to extract the attachments from emails all from the command line or the terminal. And this is the email dump.py script, which I'll have linked down below. And this is actually part of the Dier Stevens suite of tools, which we're going to cover some more of these tools later on. And so to get this script, well, we can just click on the raw view here. And we can simply w get this URL. However, you should already find it in the tools folder. And so to run it, I'm just going to call Python 3 and back out into the tools folder and find that email dump.py script. And to get some usage information, I'm just going to append the tag for the help page. And if we scroll up, we can see basically the options of how to use this tool. So essentially, we just need to provide it the mime file along with any options that we want to include. So to start off, I'm just going to provide it our sample email and hit run. And so you can see it extracted multiple parts of this MIME file. And it breaks it down in different indexes. For example, we have the header information here, but then we have the HTML content of the file. And lastly, in this fourth header, well, we have the quotation.iso file that we want to extract. And so to extract this, well, we just need to modify our command and specify the stream that we want to collect. In this case, it's four because this fourth index here is the stream of the quotation.iso file. We also want to provide the tac d argument to actually do the dump itself. And if we just run this as is, well, it's going to print everything to standard output or to our terminal, which we don't want. So, I'm just going to direct the output into a quotation.iso file. And if we just run that, you can see there we have the quotation.iso file. So again, that's another way to extract attachments without having to use the GUI of your email client. So now that we have our attachment extracted, I'll demonstrate how we can collect its file hashes on any Unix based operating system like Linux or Mac OS. And so there are three commands that we need to remember depending on what hashing algorithm we want to collect. So the first one here is Shaw 256 sum and then we just need to provide the name of the file. So if we run quotation.iso, well there we go. We're getting the Shaw 256 sum of the quotation.iso file. Similarly, we can also change this to get other hashes as well. So if we were to change this to Shaw 1 sum, well, we're getting the Shaw 1 hash of the file. And lastly, we can just change this to MD5 sum to get the MD5 hash as well. Alternatively, we can run all three commands at the same time and separate them with two amperands to run them consecutively. And you can see here we're getting all three hashes, which is very useful for our documentation. And so now that we have these three hashes, we definitely want to document them and note them in our reporting or ticketing system. And unlike IP addresses or URLs, we typically don't need to defang hashes in any way since they're just fixed length strings of data. I also want to demonstrate the email IOC extractor tool that I showed in the previous lesson. So I'm going to go back into the tools directory where I have my eioc.py pi script and I'm going to call it with Python 3 and then I'm just going to provide the name of the email. And if we run it on sample one, well, we can go all the way down to the extracted attachments. And you can see here we have the file name of quotation.iso as we expected. And we also have the MD5, the SHA 1, and the SHA 256 hash. So using this tool, it was technically safer because we didn't even need to extract the attachment manually. And we also have a nice output that we can then copy for our documentation. So next I'll show you how to do this similar thing on a Windowsbased machine. Now luckily we're not just limited to Unix based systems because it's just as likely that you'll be using a Windows machine over something like Mac or Linux at some point in your career. And luckily we can also extract the same hashes using the ever useful PowerShell scripting language. So, I've switched over to our Windows lab here, and we can navigate to the same extracted attachment located in the fishing analysis folder, specifically in the attachment analysis folder. And if I run a dur to list out the files, well, we can see we have the same quotation.iso file. And so, all we need to do now is run the get file hash command and provide the name of the file. So if I type in get-file hash and then provide the name of the file with that dot /sourcing I can just hit tab to autocomplete and then I'm just going to hit enter and you can see by default we got the Shaw 256 hash and so if we don't provide any parameters well we will get the Shaw 256 hash by default but of course we can also get different hashing algorithms as well. For example, if we wanted to get the MD5 hash, well, we can simply add the TAC algorithm flag and then provide MD5. And if we run this, well, you can see that we're now getting the MD5 hash. And of course, if we go back and change this to Shaw 1 and hit run, well, we're getting the Shaw 1 hash. Now bear with me because I had to zoom out a little bit, but we can combine all three commands together using the semicolon character separating each command. In this case, if we hit run, we're going to get an easyto- read output of all three file hashes that we can then copy for our report. So now that we have the hashes associated with our suspected file, we can now use some file reputation services to gather more information about them. And these file reputation services are like online databases that store information about files including their hashes and metadata and historical behavior. And these services will collect data from various sources like antivirus vendors or security researchers and user submissions. And one commonly used file reputation service is called virus total which we looked at in the previous lesson. And as you remember, Virus Total can aggregate data from multiple antivirus engines and other sources to provide a comprehensive analysis of URLs and files. We used it previously to analyze suspected URLs, but we can perform file reputation checks with it as well. And you can see that we can directly upload a file itself or under the search tab, we can input a Shaw 256 hash. And so the decision to upload either a file's hash or the file itself to Virus Total depends on a number of factors, specifically our organizational policies, as well as the nature of the suspected file and also what our objectives are. My personal recommendation is to only ever upload a hash to Virus Total. Imagine if you had a suspected file like an invoice, but it turns out it was actually clean. Well, if you submitted it to Virus Total, anyone with the enterprise subscription will be able to download it. And so by uploading a file hash, well, it's considered generally safer from a confidentiality perspective because it does not expose the actual contents of the file to any third party. In many cases, SOCK analysts might initially opt to submit the file hash to Virus Total for a quick assessment of its reputation. And if the hash lookup yields any inconclusive results, or if further analysis is needed, we might then choose to upload the file itself after some more thorough examination. but typically we'll have more private means for dynamic analysis like Joe Sandbox assuming we have a company subscription. So in this case let's copy the file hash. Specifically I'll use the Shaw 256 hash and head over to virus total under the search tab. I'll paste in the hash here and hit enter to run. And you can see almost immediately we got our results returned with 43 out of 61 security vendors flagging this file as malicious. And if we start to look at some of the analysis here, we can see that many of these vendors indicate it as a Trojan backdoor. Some vendors are even associating it with a specific type of malware. And if we look under the details tab, well, we can get some more information as well. We can also get the MD5 hash and the SHA 256 hash from previous uploads and reports. If we look under history, we can see when it was first submitted all the way back in 2020. We can also see some other names of this file and these are file names that would have been associated with the exact same hash which is also very interesting and useful for us if we want to do a search for something like application.bin in addition to quotation.iso within our environment. Under the relations tab, we'll see many different things. So we can actually see things like contacted URLs and domains that this piece of malware contacts during its execution. We can also see the IP addresses that were contacted. Specifically, this IP address was detected as malicious. Under the behavior tab, we can see some interesting things about the actual executables behavior when it's executed. So, we can see it's making an HTTP request for some reason to get the root certification from apple.com. But we can see it's also resolving some other DNS names. And we can see that it's actually dropping a file. In this case, this protected_68A4BO.exe file. And lastly, if we go under the community tab, we can see some other results. For example, we have an any run scan here, which shows that the verdict is malicious. We also have some other checks here that we can dive into should we want to. But it's very safe to say that this file is indeed malicious. Another tool that we can use to perform file reputation checks along with even IP or URL or domain reputation checks is Cisco Talos. And Cisco Talos is a threat intelligence and research organization operated by Cisco systems and it specializes in providing advanced threat intelligence and research and analysis and other cyber security services to help protect against a wide range of cyber threats. And so if we scroll down here to the intelligence center, well, we can simply paste in the SHA 256 file hash of our suspected malicious file. So I'll paste in that hash and click on search. And if we scroll down here, we can see much like with Virus Total, this file has been determined to be malicious. And we can see very similar detection aliases that we saw on Virus Total. Like with all of our checks and analysis thus far, we always need to ensure that we're documenting our findings during the process. So we can take screenshots of our virus total or Cisco Telos outputs or even having reports downloaded are great methods to ensure the information is not lost. We can actually copy the links to virus total scans, but we can't always assume that these links are going to be accessible as our only documentation. So, it's always important to manually collect this information and even collect screenshots as much as possible because of course having strong documentation in our tickets ensures that the organization has a clear record of all of the analysis that we performed including the files that were checked and the hashes and of course the obtained reputation verdicts. And of course, this documentation is critical for us when it comes to making verdicts and taking appropriate actions. For example, if we find a file to be malicious and we take defensive actions to block the sender and perform a deeper investigation into the user's computer, well, we need to have documentation in place to justify why we took these actions. So, hopefully that was a nice overview of how we can investigate file attachments using their reputation from their hashes. In the next lesson, we'll look at some more dynamic attachment analysis and also some sandboxing capabilities. So, let's talk a little bit about dynamic attachment analysis and sandboxing. And sandboxing is a security technique used to isolate potentially harmful files from the rest of our system. And when it comes to fishing attachments, well, sandboxing involves opening the attachment in a controlled environment separate from the user's actual system. And this controlled environment is known as the sandbox. And it mimics a typical operating system but ensures that any malicious activity within the attachment well is contained and cannot harm our actual computer or network. And so by using sandboxing and dynamic analysis tools for fishing attachments well we can analyze suspicious files safely and determine if they contain malware or other threats. And we can do this by documenting things like the behavior of the file. And so typically when we want to perform dynamic analysis we're looking for four common things. So the first is the process activity, right? So what processes are being spawned and what is the parent child relationships of these processes. We also want to look at any registry changes and so are there maybe any persistence mechanisms being executed with the file. You know, is it writing or overwriting any of the Windows registry entries? We also want to look at network connections. So we want to look at things like what connections does the file make when it's executed, right? Is it talking to anyone on the internet? Is it communicating with some sort of C2 or command and control server? And lastly, we want to of course look at file activity. So, is it dropping any other files or is it writing anything to the disk in any way or modifying any files? And in the field, you might use some proprietary tools or dedicated malware analysis VMs. But for this lesson, we're going to look into free online platforms to perform this analysis for us. And I'll say if you're interested in this topic and you want to dive deeper into building your own malware analysis lab, well, I can definitely recommend TCM's practical malware analysis and triage course produced by Matt Keley or Husky Hacks. And in that course, well, you will go through building a malware analysis lab and doing things like performing static and dynamic analysis along with a number of other topics like decompiling and disassembling malware or performing shell code analysis and more advanced maloc analysis as well. And so I highly recommend that course if you're interested in going down the route of malware analysis. And so let's locate some files that we can use for our dynamic analysis and sandboxing. And so let's go into the fishing analysis folder and head to attachment analysis and then go into the malware samples directory. And from here we'll see a couple of samples of real genuine malware that we can use for our analysis. And the first tool that we'll look at is called hybrid analysis. And hybrid analysis is a free malware analysis service that can detect and analyze malware and is powered by the CrowdStrike Falcon Sandbox, making it a very powerful and accessible tool for analysts to use in the field. And optionally, you can create an account on hybrid analysis to unlock some more features like the Yara search and the string search functions. Additionally, you'll unlock some more reporting tools as well. But for this example, we won't even need to create an account. And with the samples that we submit, hybrid analysis will generate and provide us with a detailed report about the observed behavior and activity on the simulated endpoint. So now that we're on the hybrid analysis site, we can simply drag and drop a file for analysis. Alternatively, we can open up our file explorer here and I'm just going to locate this DOCX document or this Word document. And so I'm going to double click on that to select it. And you can see we're presented with some options. Now, we can enter an email address if you want to be notified when the analysis is complete. So, because this is a free service, well, sometimes you'll be behind others in the queue and you'll have to wait a little bit to get your report. You can also provide a comment, which is optional, to basically describe your sample. Now, I'm just going to click on this to agree to the terms and make sure that I'm not a robot. And then I'll hit continue. And from here, we get some more information as well as some options for our analysis. For example, we can get the mime type of the file as well as the SHA 256 hash if we hadn't already. And interestingly, we can choose what kind of machine we want to use for our sandboxing. In this case, I'll leave it at the default Windows 10 64-bit, but we can also choose Windows 11 or Windows 7 machines, even Linux, Mac, and Android. However, I believe you need an account to use some of these options. And if you click on runtime options, you can see we get some more options available to us. So we can choose a runtime action script where we can simulate some user behavior. We can also choose the duration as well as any custom command line options or commands that we want to run when the system executes. If for example you upload a file like an office document or PDF that requires a password prompt, well you can put that in here. Additionally, if you upload a password protected zip file, you can also put in the password. We also have some other options here, but I'm just going to go back and keep everything default. And I'm simply going to click on generate public report. And remember, this is a public report. And anyone in the community would be able to access the report and look at things such as screenshots or even strings that were extracted from the file itself. So, I'll stress this again. Make sure we're not submitting anything here that is potentially sensitive. And if you're not sure, it's better to air on the side of caution and use some of the other analysis methods that we've covered thus far. So, I'll click on generate public report. And we might need to wait for the report to load, but you can see already this was classified as malicious, likely because it's been reported before. We can also see a specific CVE number that this file or this malware was labeled as. And if we look up the CVE number itself, we can get some more information. It appears this CVE affects a number of Office versions and allows remote attackers to execute arbitrary code via a crafted document. If we scroll down to the antivirus reports, we can see the Meta Defender report is currently running. However, we have a CrowdStrike Falcon report that we can also look into. And from here, we can see with 100% confidence the static analysis and machine learning capabilities detected this file as malware. If we scroll down to the Falcon sandbox reports, well, this is where we can actually see the dynamic analysis in action. This is the one that we submitted on our Windows 10 machine. But we can see this file was already analyzed on a Windows 7 machine. And so while we wait for ours to finish, we can take a look at this dynamic analysis. And we can see at a high level there were 19 malicious indicators. And if we click on this to view more information, we'll be taken to the actual report of this dynamic analysis. So again, we can see the result of this analysis was malicious. While waiting for the report to finish, I was looking into the CVE number that we identified. Specifically, it appears that there's an attack chain that we could potentially look for in our report. First, an attacker is going to target a user with a Word document. And this Word document is going to have an OLE2 embedded link object inside of it. And when the user opens this document, well, the Microsoft Word executable is going to issue an HTTP request to the attacker server to retrieve a malicious hta file. The file that's returned by the server is going to be a fake RTF file with an embedded malicious script. When Word tries to handle this script, it's going to inadvertently invoke the Microsoft HTA application or MSHTA.exe, which will then execute and run the embedded malicious script. And in this medium link, which I'll have linked down below, we can see a more visual representation of this attack chain. So, with that in mind, let's return to our report and see if we can identify any of those indicators. Right off the bat, of course, we can see that this was identified as malicious. Now, we could technically write off our report here and be fairly confident that this was a malicious file. And if it was attached to an email, well, we could be very confident that that was a fish and respond appropriately. However, let's look into this report in more detail so we can understand its components. If we scroll down, we can immediately look into those 19 malicious indicators. Starting out, we can see we identified some exploit or shell code that was related to that CVE number. And if we scroll down some more, well, this starts making more sense. We can see that the sample executed some get requests to download files from a web server. Specifically, we can see the request itself. We can see the host, which was potentially the attacker's command and control server or the server that they were hosting the second stage of the malware on. We can also see the URL itself. If we scroll down to the get line, we can see the actual file that was downloaded, this doc file, which in the case of the attack chain we identified, this is most likely the fake RTF file, which has the embedded malicious script. If we scroll down some more, we can identify that the file spawned a number of processes, which is definitely something we want to look into. And specifically, we can see that the file spawned a number of PowerShell processes, which is very suspicious. A Microsoft Word file should not be spawning PowerShell.exe. We can see that the malware is attempting to configure Windows Defender to exclude specific file paths from its scanning and protection mechanisms. Likely this is an attempt at AV evasion. And we can see the two executables that were excluded from scanning. And this is very useful for our notes. And under these processes, we can see another one here which appears to be a potential persistence mechanism. In this case, we can see that a new scheduled task was created using the Windows taskuler executable. And specifically, we're seeing the same name here that we identified earlier. If we scroll down some more, we can get to the screenshots section. And in this section, we can see some actual screenshots that were taken on the sandbox machine itself as it was executing the file. And if we scroll through these, we might get a better idea of what actions were performed on the sandbox. Specifically, we can see that Microsoft Windows was opened, but the file appears to be blank. If we go under the network analysis section, we can see some DNS requests that were made. Specifically, we have these two domains here, which appear to be the attacker's command and control server and potentially the server that was hosting the stage two of the malware. In this case, TT.VG is in fact yet another URL shortening service that the attacker seems to be leveraging to disguise a malicious URL. And we can also see the IP addresses of these domains along with some additional information like the register and the country they belong to. And in line with the attack chain we identified, it appears that the Winword or the Microsoft Word executable was in fact making those HTTP requests over port 80 and 443. And it was making these requests to that TT.VG domain which we identified was hosting the fake RTF file that had the embedded malicious script. Under HTTP traffic, we can see the actual request that was made to the web server. Specifically after some redirects, it appears to be this request here as we can identify by the same file name in the URL. If we go to the extracted file section and scroll down, we can in fact identify that fake RTF file. We can even take that SHA 256 hash and head over to Virus Total for more analysis. If we paste in the hash and run the scan, well, we can immediately see that over half of these security vendors flagged this file as malicious. Now, that was quite a bit of information, but the main thing that we can take from this is just the large amount of malicious indicators that we found. And so, it's no question that this file is malicious. And if it was attached to an email, well, we can definitely write the email off as fishing and respond appropriately. Now, we also have Joe Sandbox. And Joe Sandbox is a very powerful malware analysis engine. And it allows us to analyze files on Windows or Mac and even Android operating systems. But unfortunately, Joe Sandbox requires us to register with a business email and they will manually verify your account. And so because of this restriction, I'll quickly showcase it here, but we'll stress that hybrid analysis is a much more accessible option. But fortunately, with a business email account, we can access the Joe Sandbox cloud basic tier, which limits a number of configuration options such as custom commands or browsers and network options, but we'll still have access to some really useful features. For example, I'm going to upload the same file that we've been using. And scrolling down, I can select the analysis system. And we have access to Windows 10 or Windows 7. For this case, I'll just leave it on Windows 10. And now we have this option for live interaction. And this will allow us to dynamically interact with the sandbox as needed. And so I'll check this off to demonstrate. And I'm also going to check off generate deep analysis report after execution. Now we can enter some settings here like we can add a comment and change the execution runtime. And we can click here to show the advanced settings. So, we can do things like turning off internet access, which we don't really want to do. And so, I'll just leave everything as default. And before we analyze here, remember once again, anything we submit here is going to be published and accessible to anyone. And anyone will be able to download the sample as well as look at the screenshots. If we want to run private scans, well, we're going to need to pay. And so, with that in mind, let's click on analyze with Joe Sandbox, and it'll give us that warning once again. And so right now our sandbox machine is booting up and you can see it's opened up to the Microsoft Word document and we can interact with this sandbox, right? So I can close it and reopen it. And you can see already we're getting a number of signatures and IPs detected. So I'll wait for the report to finish to start looking at these. But just note that this is an interactive environment. I can type whatever I want. And this is very useful if we're dealing with embedded files or objects or scripts within a Word document, for example. And we can dynamically interact with the document and click on any links that we need to or download any files from a Google Drive, for example. And so this is why sandboxing is so useful for us as a sock analyst if you're trying to do more deep investigation. And so I think we've let this run for long enough. So I'm just going to hit stop in the top right here. And now Joe Sandbox is going to generate that deep malware analysis report for us. But we can already see some interesting things here. Specifically under signatures, well, we can find a number of malicious identified signatures. If we look in the IP section, well, we can see some IP addresses that were contacted. Specifically, we have three down here that were identified as clean. These are most likely normal Microsoft IP addresses. However, we have the same 172 address that we identified earlier as malicious. Under domains, we can see that TT.VG domain that once again was identified as malicious. And we can even see the URL that was hosting the second stage of the malware. So after a few minutes, the report is finished and ready for us to take a look at. And we can see immediately the file itself was identified as malicious. And if we look down, we can start to see some IoC's, specifically the IP address and the domain. If we click on full report here, as the name suggests, we get a full report of everything that was detected and run. If we scroll down, we can immediately see all of the signatures that were detected. The red means that it was most likely malicious. Under the detection, well, we can see that there was a 100% confidence rate that this was a malicious file. And we get some more general information like the sample name, the hashes, and the screenshots from the execution. You can see this was everything that we performed when we were in the sandbox. Now, I'm not going to go into this report with the same amount of detail that I did with hybrid analysis because we should see many similar things here. So, at a high level, it's just important to note that there are other sandboxing tools out there like Joe Sandbox. Speaking of other tools, well, the last one I'll quickly cover here is called Any Run. And like with Joe Sandbox, in order to use the free version, well, you need to sign up for an account. And unfortunately, you do need a business email in order to sign up for an account. And so, as such, you don't really need to follow along here. I'm just going to showcase how to quickly start and run a scan. And as mentioned earlier, I would definitely recommend hybrid analysis due to its accessibility. And any run is an interactive malware analysis sandbox that allows us to provide things like URLs or files or even email files. And it will dynamically investigate and extract things like IoC's and look at behavior. And because it's interactive, well, we can actually interact with the sandbox like we could with Joe sandbox. And so our options are going to be severely throttled and limited with the free version. But I'll quickly showcase how we can analyze a file. And it's also important to note that anything we upload, well, we'll be publicly available. If we look at public reports here, we can see all of the public submissions from other users. And so even if you don't have an account and you're interested in seeing what the report looks like, well, you can go through the public submissions here and you can even search based on hashes or tags if you're interested in a specific sample. But to start our own analysis, I'm just going to click on analyze files here. And as you guessed, I'm going to pick the same files so we can compare the different services. So I'm going to select this bank payment document, which will open up this new analysis window. And from here, I'm just going to click on pro mode so we can see all of the options. And now we can choose a number of different things. For example, we can change the start object from where the sample is executed. By default, it will be the temp directory, which I'll leave it at, but we can also choose things like the desktop or the user's home directory. We can change some network settings. For example, we can completely disable the network from the sandbox. However, since we're analyzing malware and want to see those network connections, well, I'm going to leave it connected. And note under privacy here we only have the public option. If we were on a higher tier or a business plan or an enterprise plan, we would be able to run private scans. Under operating system here on the free tier, we only have access to Windows 7. So I'll leave it at that. And so with these selections, I'm just going to click on run a public analysis. And it's going to give us a warning that this is of course a public task. So I'm going to click I agree. And it's going to start up the sandbox for us. So you can see our sandbox and our dynamic analysis VM is starting to boot up and we can see in the preview window here it's currently opening Microsoft Word and we can interact with this machine. For example, I can click on the start menu here and I can start clicking on any of these applications. But I'll just let it do its thing and open up Word. Similar to Joe Sandbox, we can see under here some of the OC's. We can see some connections that are being made. We can see some DNS requests. for example, this TT.VG domain, what we're quite accustomed to seeing. And so once our sample is complete after that minute, we can look at the full report. Specifically, we can start with looking at some of the IoC's that were detected. And so we're getting the hashes of the file itself along with the DNS requests. And you can see here that this domain has been identified as malicious, which of course we've already found out. We can see the IP addresses of the connections along with the URLs that were contacted as well. So specifically, this was the URL that we identified previously was hosting the second stage of the malware. And so as you can tell, we're getting a number of the same information and the same classifications. For example, this of course has been identified as a malicious file. But anyone can provide us some very useful reports that we can download and put into our documentation. If we click on text report here, it's going to take us to this full report of all the behavior and activity that it analyzed. And if we wanted to, we could click on the print option here and save this as a PDF. And this would be very useful to include in our report or documentation. And just to very quickly cover this report, but we can see very quickly under the tags here, we're getting that same CVE number. We're also getting the file hashes as well. But as we scroll down, you will see a number of interesting sections within this report like the behavior activities or the screenshots from the report itself and all of the processes that were captured along with this behavior graph. We also of course get things like registry activity and file activity and of course network activity as well. And like with all the tools and solutions we've looked at in this lesson, they all provided us with very interesting information and also gave us a verdict on the malicious activity of the file we submitted. And just to wrap up, like I said before, sandboxing is a very useful technique for us and it can really allow us to do some deeper analysis on files that we haven't been able to determine are malicious or not. And through using interactive sandboxing tools, we can do interesting things like safely download files or browse through malicious URLs. And so I'll leave it with the sentiment that dynamic analysis and sandboxing is always going to be a very useful tool in your arsenal, but it should never be the only thing that you rely on. And so I hope this was a good introduction into some of the options out there. Before we dive into our next section, I just want to again thank our sponsor for this video, Flare Academy. Cyber threats are evolving fast and staying ahead is not just an advantage, it's a necessity and that's where Flare Academy comes in. Flare Academy is an educational hub designed to democratize cyber security knowledge. Backed by the Flair research team and leading threat intelligence experts, they provide accessible training, collaborative discussions, and cutting edge resources. With the support of Flair's industry-leading research team, members gain access to hands-on insights and training while connecting with peers and experts to tackle the toughest and newest challenges together. This is through practical sessions designed to solve real world cyber security challenges. The opportunity to engage with industry leaders, researchers, and fellow professionals to grow your skills, community meetups to share insights and experiences in both virtual and in-person events, and exclusive research and tools such as access to cutting edge reports, tooling, and intelligence from Flair's experts tailored specifically for the community. With Flare, you can learn and grow through in-depth training sessions on credential management, reconnaissance techniques, OSENT, and much more. Delivered by industry leaders like Jason Hadex, and backed by Flair's research team, you'll get exclusive access to expertly crafted solutions, playbooks, and session materials designed to address real world cyber security challenges. You'll be able to participate in expert-led discussions and Q&A channels and stay ahead of emerging threats with exclusive reports, feeds, and insights from Flair's comprehensive cyber crime intelligence. And verified members gain access to premium resources and private insights while contributing to a community that thrives on shared knowledge. And so, if you're ready to level up, join Flare Academy today through the link in the description. Now let's take a very basic look into performing static analysis on malicious office documents or malocs. And I really mean a basic analysis. I don't want to turn this into a malware analysis course. For that expertise, I would once again suggest the practical malware analysis and triage course by Husky Hacks. And even performing some of this analysis is a bit of an overstep and most likely not something you'll have to do in the field. However, I still think a basic analysis of Malddocks can fit nicely into this section because you will definitely come across malocs or macro enabled word files or Excel files very often in the field. You know, if we think about the ubiquity of office software, we have tools like Word and Excel and PowerPoint. And while this ubiquity is a gold mine for attackers to try to exploit due to the number of organizations and businesses that use them daily. And so a maloc is short for a malicious document as you probably suspected. And it refers to a weaponized document file such as a word document or an Excel spreadsheet or even a PDF that has been crafted and modified to carry out malicious activities when it's opened. And so commonly this is done through things like macros embedded in the file or different embedded objects. And so macros are scripts that are embedded into these Office documents that can be programmed to execute a series of commands automatically. And so when a user opens a document and enables the macros, well, these scripts can run without further interaction. And macros are a legitimate and powerful tool that can be used to automate repetitive tasks in these files. However, of course, this power can also be exploited to run system commands. And attackers can write malicious macros to perform things like downloading and executing malware or stealing data or altering system settings or even providing remote access. And since a lot of end users might not fully understand the implications of enabling macros, well, they can quite easily be tricked into enabling them and allowing this malicious code to run. And VBA or Visual Basic for applications is typically the language used to write these embedded macros. And so to effectively analyze Malddox, well, we can combine various static and dynamic analysis techniques. And of course, in the previous lesson, you learned how to dynamically analyze samples in an online sandbox. And this is typically as far as you're going to need to go. But in this lesson, we'll quickly look at a simple utility or tool that can carve through these Office documents and find potentially malicious embedded content. And ultimately though, no matter our method, well, our goal is going to be to determine, of course, if the document contains malware and if we can extract specific indicators of compromise like IPs or URLs or domain names or even specific scripts that we can then use to fuel our team's threat intelligence and detection capabilities. And because we're going to keep it short, I'm going to introduce you to one simple tool called OLED dump.py. And you might recognize this repository because it's part of the Dier Steven suite of tools that are very useful for analyzing these types of files. And previously we used the email dump.py script to extract attachments from emails through our terminal. And this script will be linked down below, but I have also included it in the tools folder. And so what does OLE mean, right? Well, OLE stands for object linking and embedding. And it's a technology developed by Microsoft that allows embedding and linking to documents and other objects. And so, OLE is used in all of these different Microsoft Office applications like Word and Excel and PowerPoint to embed objects like spreadsheets or charts or images. And so, you can think about how you're able to embed or link Excel charts or tables and other objects into Word documents or within a PowerPoint presentation. Well, OLE is the underlying technology that makes all of that possible. And OLED dump.py will allow us to dig into this embedded media and look at different properties and components that make up the document. And so to get started, let's navigate to the MALDOC analysis folder. And from here, we can see an attachment with axlsm file extension. And this extension is typically a macro enabled Excel document. And in this case, we suspect that it might have a malicious VBA script embedded inside of it. And so it's honestly quite simple to use this tool. I'm just going to call Python 3 and back out into our tools directory to find that OLED dump.py script. And from here I'm just going to provide the sample name. And a lot of work has already been done for us. So you can see that OLE dump kind of carved into this file and assigned indexes or data streams that relate to different portions or sections of the document. And again to keep things concise, well we can see this capital M here. And this means that there is an embedded macro in this specific index stream. And so now that we know the stream is this fourth index here, well, we can run this command again and specify the fourth stream. And that might be hard to see because it's cut off, but that's just a tac s with the number four. And so if I run that, well, we're now getting an entire hex dump of that macro. So these are the raw bytes. And of course, this is pretty hard to read on its own, but we can almost start to make out some interesting things. For example, we have an HTTP protocol here, apparently going to some sort of IP address and some URL. So, let's look at this in more detail. What we can do is append to our command the capital S flag. And this is like running strings against the file or the macro. So, if we run this, well, we've started to extract some strings. And again, this also isn't super interesting to read, but we can see some things like the invoke web request. And if you're familiar with PowerShell, well, this is a way to make a request to a URL. And we can see the URL or the URI here. And again, it looks like there is an IP address with a file extension. Now, the final command we'll run, let's take out that capital S and run something to actually attempt to extract the entire VBA script. So, with that, we'll do two dashes and then we'll type in VBA decompress corrupt. And it's an odd name, but if we run this, we should extract the full VBA script. And you can see we've done that here. And in this case, this is the interesting OC using the invoke web request function. Well, it's making a request to this URL. And this URL is simply an IP address that of course we can do IP lookups on. And we can actually see it's downloading an executable file. And then through this start process command, well, it's actually executing the file that it downloaded. And so in summary, this macro is designed to run a hidden PowerShell command that will download and execute a file from this URL. And of course, we can infer the overall intent here is likely to run some sort of malicious code and executable on the user's machine without their knowledge because this will run in the background when the file is opened. And so I'll admit this kind of static analysis is a bit out of scope for the course. You know, it's doubtful that you'll be expected to do this kind of analysis on the job. And you're typically much better off simply analyzing file hashes and performing dynamic sandboxing as necessary. But I thought it would be very interesting to include a quick demo here because it's such an easy script to demonstrate and it's really a good foray to those who are interested in more in-depth malware analysis. Along with malicious office documents, well, one of the most prevalent attachmentbased threats that you'll encounter as a sock analyst is malicious PDFs. And similar to the previous lesson, we're not going to do a full curriculum on static malware analysis. However, I think that understanding the composition and structure of PDFs along with some simple tools that we can use to dig and carve into them to find anomalies and embedded content can benefit your overall comprehension when it comes to analyzing attachments. To be honest, in most cases, attackers don't even go as far as to embed malicious content within PDF files themselves. I would argue that the most common technique that I've seen in the field involves simply containing a clickable URL within a PDF file that then leads to a malicious web page or drive by download. And the reason why an attacker would use a PDF to send a simple payload like a URL is due to things like user trust and familiarity and potentially the ability to evade email filters. For example, most organizations will allow for PDF attachments since it's so widely used across organizations for a number of different business purposes like invoices or forms or policies. And as such, users are very accustomed to receiving PDFs and will typically trust them more than any other file type since they interact with them daily. Additionally, email gateways and email security technology may not have the capacity to open up the documents themselves and statically analyze or extract any URLs within the content itself. So it becomes an easy payload delivery option leaving organizations to rely on their EDR or web proxy or network traffic analysis solutions. And just as an example, let's go into the Malddock analysis folder and then into the PDF directory. And I'm just going to open up statement.pdf. And this for example is what one of these PDFs might look like. And so you can see here we have some communication impersonating Amazon. And with a common pretext that we've seen so far, it appears there's been some unusual activity on our account and our account has been placed on hold. And the main point of this PDF is to get the user to click on this link here, which most likely leads to or is led to a credential capture page. And for example, we can get the hash value of this file. And as we're used to doing already, well, we can search for this on something like virus total. In this case, it doesn't appear that there were any matches found for this PDF document. And so, what should we do now? Well, assuming we never opened up this document, well, we can still open it up and carve into the file via the command line. And there are ways for us to extract any embedded URLs or files or scripts directly from the terminal. And one of these tools that we'll start with is called PDF parser.py. And it is part of that Dier Steven suite. And it's designed to parse and analyze the structure of PDF files. It allows us to inspect the contents and extract or analyze embedded objects or search for specific elements. And by doing this, we can detect any potential malicious content. And so, let's run this tool on the file. And you'll find it within the tools directory. And for the argument, I'm just going to simply provide the name of the file. And so we can get a better output, I'm going to pipe this over to the more command so we can scroll through the results. And as we run this command, well, we can immediately see some interesting information. And so PDF parser is going to carve through the file and extract any of the objects found in the makeup of the PDF itself. In this case, this first object here was able to extract a link in the form of a URI. And specifically, we were able to extract the exact URI that we found when we opened up the file. And so, of course, this is a useful IC for us. And although we didn't get a hit on virus total for the files hash, well, I'm going to copy this URL and see if we can find anything about its reputation using this web artifact. And so I'm just going to paste it in here and hit run. And when doing that, we can see that at least one of 94 security vendors flagged this URL as malicious. And we can see in this one example, it was flagged as fishing. And so I would typically expect to see more here. But given the fact that it's using a legitimate Google service and it was probably taken down quite quickly, well, we don't have many results to go off of. But being able to extract and analyze the URL itself instead of just the file hash gave us a bit more to go off of. So let's look at another example here. In this case, we can look at the book04 PDF. And in this example, it appears the attacker is using a blurred image to make it look like there's a PDF on the other side of this download link. And of course, we can extract the URL from the PDF itself. But we can also do it through safer means in which we don't need to actually open up a PDF viewer. In this case, I'll run PDF parser again and provide that book file. we do end up getting a lot of information. But since we're looking for a URL, or rather a URI, what we can do is make a slight modification to the command. We can add the S flag to search for a specific object. In this case, I'm going to search for / URI. And you can see we were able to pull back this URI object specifically with the URL itself. And so once again, if I copy this URL and take it over to Virus Total, I can paste it in and do a search. And in this case, we have two instances of vendors flagging this URL as malicious, which gives us a bit more to go off of. And remember, I'm just using Virus Total here for a short example. But as discussed in the URL analysis section, well, there are so many tools that we can use at this point to analyze the reputation of URLs and domains. And so that was just two quick examples of how we can extract and identify any URLs embedded inside of a PDF without having to open it in any PDF viewer. Now, let's talk about PDFs that can be a little more sinister and actually contain things like embedded malware or scripts or even documents. Well, in this case, we'll use this example to go off of. And this is a test PDF file developed by Dier Stevens that we can use to test some of the tools like PDF parser or PDF ID, which I'll cover next. And PDF ID is a lightweight tool that can scan a PDF file and provide a highle overview of its structure. And in doing this, we can of course identify any suspicious elements or objects that shouldn't be there like JavaScript or embedded files and other open actions. And so it's quite simple to run. I'm just going to call Python 3 and go back into the tools directory and call PDF ID.py. And then I'll simply provide the name of the file as the argument. And in this case, we get a very easy to read output of all of the components and objects that make up this PDF file. And as I mentioned, there are a couple of objects that we typically want to look out for when analyzing a PDF. For example, we want to look for any JavaScript or JS objects, which would indicate that the PDF contains embedded JavaScript. And we can see that this file has both JS and JavaScript objects. And these embedded scripts can be used to potentially steal data or make connections to an attacker's server or attempt to start and execute external programs on the victim's system itself. We also want to look for any open actions, which we can see this file has one. And open actions can potentially cause the PDF reader itself to take some sort of action when opening the file. And we also want to look at any launch objects. Again, this could be used to potentially launch some external software when the PDF is opened. And of course, we want to look for any embedded files. In this case, we can see that there is an embedded file. It's possible for an attacker to embed malicious files like macro enabled word documents or malware into the objects of the PDF itself. And so, we can use PDF parser to extract the embedded files contained in the PDF and also look at any embedded scripts. And so, I'm just going to call PDF parser and provide the name of the file. And again, I'm going to pipe it to the more command. So we can scroll through the output. And so we can see this first object here, this catalog object is referencing a file called EIC dropper. And this is probably the embedded file. But we can continue scrolling through this output to find the actual object that contains the file. As we scroll through, we can see object 7 here, this filespec object is making another reference to this doc file. And we can see object 8 here actually refers to the embedded file object. And so we can see the file's data stream along with its length. And so we can actually extract this file. But first let's take a look at object 9. In this case it appears to be the embedded JavaScript. And it's telling the PDF viewer to execute JavaScript code when the action is triggered. And it appears to be attempting to launch the dropper document. And so let's go ahead and extract the file. And of course we can do this through PDF parser itself. So I'm going to rerun the same command here but I'm going to provide some additional arguments. For example, we identified that the object containing the embedded file is object 8. And so let's provide that using the double dash and then object argument. Next we can see that the file itself has been encoded. And so we can provide the filter flag to decode the data stream. We also want to provide the raw flag to display the output in raw format. but we don't want to display it to our terminal. So lastly, we want to provide the dump option and save it to a file. In this case, I will call it the same name that we've identified through the file itself. And so with all of that set, I'm just going to hit run. And we can see that the file was decoded. If I run an ls, we can see the eicar dropper.doc. And if I run the file command on this file, we can see that it's a composite document file version 2 document. And this is an older Microsoft Office document format that can contain embedded macros. And so since we've extracted a doc file, well, we can perform similar actions that we did in the previous lesson to look for any embedded macros or malicious scripts inside the document. And if you remember, we use ole dump.py to do that. And so just as a quick example, I can run it against the file where we can identify the module one macro on the seventh index identified by the capital M. And so I'll leave you to do any further analysis on this macro if you'd like. But at a high level, we covered some various methodologies and tools that we can use to either extract URLs from PDFs or extract any embedded media or scripts. And similar to the previous lesson, checking the files hash reputation and potentially performing any dynamic analysis is typically the quicker and easier option in the field. And you'll typically not be required to go in depth into static analysis or even perform static analysis at all in the day-to-day. But I thought it would be interesting to include some basic methodologies and syntax within this section. And so I hope you enjoyed. Now, wouldn't it be great if we could expedite the fishing analysis and triage process with some automated extraction and enrichment and analysis? Well, we've covered some tools and scripts already that can simplify the artifact collection process. But is there some sort of magic solution out there that can take all of the manual effort off of our shoulders? Well, I wouldn't say it's a magical solution, but in this lesson, I want to introduce you to fish tool, which is a web-based fishing analysis solution that allows analysts and researchers to quickly and automatically analyze and categorize emails and generate investigation reports. And so, using fish tool, we can gather contextual analysis of email metadata and URLs and attachments and quickly turn those into actionable findings. And now there is an enterprise edition of fish tool. But fortunately we can do all of the analysis we need using the free tool. And so I'll have this site linked down below. And so we can just click on get fish tool now for free. And of course this is going to require an account. So we can just sign up here. And fortunately we don't need a business email account. So you can use any Gmail or Yahoo or Hotmail account that you want. And once we're signed in here you can see we're taken to this dashboard. And once we start uploading some emails to analyze, well, this is going to start getting filled up with interesting charts and graphs. But we can start by analyzing our first email. So we can either head over to the analysis section here or just click on this blue analyze button. And upon doing that, you can see we can drag and drop an email or we can just click on choose file to select one from our explorer window. And from here, I'm just going to go into the fishing analysis section and go to the header analysis. And from here, I'm just going to select sample one. And if you remember that was the Chase Bank Fish. And so it's going to upload. And you can see we immediately have a number of useful indicators. On the right hand side, well, we can see a rendered version of the email. If we click on HTML, we can see the actual HTML markup that makes up the content or the body content of this email. If we click on source, we can get the full source of the email file, which is what we were looking at when we opened it up in Sublime Text. And on the left hand side here we can see some interesting artifacts that were automatically collected from the email. For example, we have the subject line at the top. We have the from and the to header. We have the timestamp of the email. We have the reply to and the return path along with the originating IP and the RDNS or the reverse DNS. If you remember, this is the resolve host field that we were looking at when we were doing the IP lookup. In this case, Fish Tool conveniently did this lookup for us. And we can see the proton mail address. Now you'll notice some exclamation marks next to reply to and return path. If we click on the exclamation mark, we can get some more details as to why this was flagged. And of course, this immediately highlighted that the reply to email address is inconsistent with the from header, which of course is something suspicious that we should keep in mind. The same deal if we look at the return path, we can see that the domain name proton.me is inconsistent with the chase.com domain from the from address. If we click on the received lines tab, we can get all of the different hops or the MTAs that the message traversed through on its way from the source to the destination. And these are all extracted from the received headers. We can see we get the timestamp and the mail server that sent it and received it. In this case, we can get the IP address of the original mail server, which was of course that proton.ch. This tab makes it really easy for us to look through each of these hops. under the X headers. This is going to specifically extract any of those extended or custom headers. You can see we get the X sender IP under here as well. Under security, we also have some additional flags. We can see that SPF has passed because the resolved host was proton.ch which matched the originating IP. However, if we scroll down, we can see that demark had failed because of the spoofing attempt of chase.com. If there were any attachments on this email, well, we would see them in the attachments tab. However, we can go over to message URLs where we will conveniently find that DSGO.TO address. Now, fish tool can even do things like integrate virus total. However, to configure this, we need to generate a virus total API key. I'm not going to show going through that in this lesson, but that is something you can do if you're interested. This will allow you to get virus total insights on any attachments and URLs and file hashes all from the same console. Once we've identified that a email is malicious or clean, well, we can click on resolve here. And in this case, we can edit the email disposition to malicious. If we click on flagged artifacts, we can choose why we decided that this email was malicious. Of course, in this email, it was the return path and reply to indicating that this was likely spoofed. We also have this URL which was using a URL shortener service to offiscate a malicious link. Under classification codes, we can choose what techniques the attacker used. In this case, we know there was definitely spoofing going on. And if the URL was still live, potentially credential harvesting as well. And from here, we can just click on resolve to of course resolve this email. And when we return to our dashboard, well, we can start to see some metrics are being filled in. Let's quickly analyze one with an attachment. So in this case, I'm going to go back to our fishing analysis folder and go under attachment analysis. In this case, I'll choose sample one that had that malicious quotation attachment. In this case, we don't need to go through every section, but let's go under the attachments tab. In this case, you can see it automatically extracted the file name along with the associated hashes. If we had our Virus Total API key configured, well, we would obviously get the result here that the file is malicious. In this case, we can just copy one of these hashes and manually head over to Virus Total. I just wanted to showcase that it's also able to extract attachments along with URLs. So, I hope that was a very interesting look into a powerful tool that we can use to automate some of the manual work. And I can't say for sure that you're going to be using fish tool in your sock, but it is definitely a useful resource to have in your arsenal to save a lot of time. So far, we've done a fantastic job at identifying and analyzing fishing incidents. However, let's think back to the sock and its role and recall that the last step in the key functions of security operations is to respond to incidents quickly and effectively. Now, what would any of our in-depth analysis and investigation be for if we did not appropriately respond to fishing incidents and take defensive actions to mitigate their impact and prevent future ones? And we can break down the defensive measures we take into either reactive, so occurring as the result of us identifying and analyzing a fishing incident, or proactive, so using what we've learned from our analysis to proactively improve our detection and security operations. And so in this lesson, let's focus on the reactive defense measures. And specifically, these are measures that we want to take in order to address and resolve the incident and minimize the risk of the malicious email that we identified arriving in employee inboxes. And assuming through our analysis we've already identified and classified an email as a fishing attempt, we typically want to take the following reactive response actions. And these response actions will typically follow the classic incident response framework after the detection and analysis phase. And we'll cover these in much more detail within the IR section of this course. But at a high level, we want to first think about containment strategies. So, as mentioned, after we've detected and analyzed the fishing incident, well, we'll need to perform some containment actions. And this involves taking immediate steps to isolate the fishing threat and prevent it from spreading further within the organization. So, the first thing here is we want to determine the scope. And for example, was this an email that was just sent to a single user or was it sent to an entire department or team? And also, was this a thirdparty contractor that rarely uses their email account or was it a high-ranking executive with access to critical systems and sensitive information? And so understanding these details is essential as they really directly impact the severity and potential consequence of the fishing attempt. And we can determine the scope either at the email header level. So, you know, where we're looking into the recipient or the carbon copy headers, and through these headers attempt to determine all of the users who receive the email. However, it's often more efficient and effective to perform this kind of scope analysis at the email gateway level. And so within a Microsoft environment, we can typically utilize the message trace functionality to determine the scope of an email message. And so using the artifacts we collected during our analysis stage, things like the sender's email address or the timestamp or even the subject line, well, we can easily identify all the recipients and copied recipients of an email. And the exact steps and procedures will be different depending on your organization's infrastructure and tooling of course. For example, in a Google or a G Suite environment, we can utilize the email log search feature for the same purpose. But no matter the tool, the methodology remains the same with the same objectives of using artifacts that we previously identified to narrow down our search and find every recipient of an email. And so now that we've identified the scope of the fishing incident, the next important step in the containment process is to prevent further spread and mitigate potential damage. And one effective containment strategy here is quarantining. And so to quarantine involves isolating suspicious or potentially malicious emails or files or attachments and prevent them from reaching end users inboxes or systems. And in both Microsoft and Google environments, we can utilize the native quarantine features to isolate fishing emails and associated attachments. And so next we can get into blocking specific artifacts. And so at this stage we've likely identified a malicious sender, a sender who is most likely related to an ongoing fishing campaign. And as such, we need to ensure that we prevent future fishing attempts from reaching users inboxes. And we can use various strategies to block sender artifacts, including things like blocking specific email addresses or domains or IPs or even subject lines of the email itself. And all of these artifacts that I just mentioned should have already been collected during our triage and analysis stage. And so again, we can block things like the specific email address, but that might be less effective against sophisticated attackers who can frequently change their email address or use disposable mailboxes. Or we can just block entire domains, and that of course can be an effective strategy, but we need to be careful because it might lead to collateral damage, especially if the attacker is using a legitimate service. We could block the IP address of the mail server. But again, we have to be very careful here. Attackers can easily change their IP address or use a different mail server. And of course, we could block the subject line of the email, but of course, that's very easy to change. And I mentioned being cautious around blocking entire domains. And so, you can imagine identifying a fishing email that used genuine Gmail or Outlook as its email infrastructure. Well, you can't just go ahead and block gmail.com or outlook.com. Of course, blocking legitimate domains like these can lead to a number of false positives and also disrupt business operations. And quite honestly, people are not going to be very happy with you, especially the IT support staff when they start getting thousands of requests as to why their emails aren't sending. So, just to give you a bit of an example on how a sock analyst may go about creating rules to block certain artifacts. Well, I've spun up a Microsoft Exchange email server in a lab environment just so we can go through some of the UI and the different options you might have to create rules. And by all means, you do not have to follow along here. It's more so just a demonstration for you to watch. If you are curious, you can look up any tutorial out there on how to set up an Exchange server, but I won't cover how to do it in this course because it takes a bit of time to set up and won't really be relevant to other sections that we'll cover here. And this will be quite similar to what you see in an Exchange online environment or a Microsoft 365 environment as well. And so, let's think about how to block an email address. For example, maybe we've identified a fishing attempt that has clearly come from a malicious mailbox or sender. Well, in an Exchange environment, we can go over to the mailflow tab and then into rules. And mailflow rules are created to define specific actions that should be taken on email messages based on defined conditions. And so these conditions can be based on the message content or sender or recipient and other attributes as well. And this section is where administrators and security staff can create and manage and modify the mailflow rules, also known as transport rules that apply to these email messages. And so to create a rule, we can just click on this plus tab here and click on create a new rule. And from here, we can start defining the conditions of our rule. And so for the name, I'm just going to put in an example name. But in my experience in the sock, we would typically categorize and set up more generic rules like email address block or domain block or IP block. And within these separate rules, well, anytime we identified a malicious artifact that matched one of these categories, like an IP or a domain, well, we would add it to this rule. We would modify and add it along to the rule instead of creating separate rules for every, you know, identifier or sender that we discover. And so it all depends on the workflow and how you want to categorize and keep things organized. But in this case, let me zoom out a little bit here. Uh we can select apply this rule if and this is going to give us the conditions. And so in our case, we're looking to match a sender, right? But you can see we can also match on different things like the actual recipient of the email or where the sender is located. So we can actually take a look in the received headers and figure out where the original mail server is located, which is pretty useful, right? But in this case, let's just choose the sender is. And I keep having to zoom out. And in our case, we can go under this box here and just type in an example email address that we want to block. So I'm just going to put test.com. And then we're going to click on okay. And you can see here we've entered test at testest.com. But if we go back in here, you can see we can actually add more individuals as well. For example, test two at test.com. So you can see how we can slowly start adding to this rule over time. And once we're satisfied with all our conditions, well, we can move on to the action section. And in this case, we can go under this dropown menu. And you can see we have different options for what we want to do or what actions we want the email server to perform once it finds an email that matches our condition. So you can see we can do things like forwarding the message for approval or we can redirect it to another mailbox. But in this case, let's just delete the message without notifying anyone because in this case, of course, it's a fishing email that we don't want. And once we're satisfied with our rule conditions and actions, well, we can scroll down and make sure it's enforced. And then we can click on save. And you can see once our rule is saved, we can look over to the right here and start walking through what this rule is going to do. So for example, if we receive an email from [email protected] or [email protected], well, we're going to immediately delete that message without notifying the recipient or the sender. And optionally, we can add rule comments here. So if we go back into the rule, we can click on more options. And you can see once we do that, we unlock some more features, right? we can start adding more conditions and start stacking multiple things. Right? So, if we click on the recipient, we can start choosing other options here like specifying if the recipient is external or internal or if they're a member of a specific group in our organization or we can start specifying domains, right? And if we scroll down, you can see we can actually add a comment. So, for example, we can put in something like fishing and maybe we want to reference a specific ticket or incident ticket that we can refer to later on. And so you can see once we've saved that, we have this rule comment now under the rule comment section. Now when we think about other sender artifacts, we don't have to specifically choose a mailbox. For example, let's create another rule here. This time I'm first going to scroll down to more options so we can unlock some more conditions and actions. In this case, I'm just going to call it example domain block. I'm just going to search for the sender and specifically I'm going to look for the domain. And in this case, we can specify an entire domain. For example, if I choose malicious domain.net, well, we can add that to our rule. And remember, we can start stacking multiple domains into one rule to keep things clean. So, now that we have some domain set here, we can click on okay. And you can see we've listed them here. And in this case, we can just delete the message once again. And I'll put in a comment once again and hit save. And you can see on the right here, our new rule is created to match any email with the sender's address matching one of these domains. Now, we can also block sender IP addresses. For example, if I create another rule here and go down to more options, well, I can go under our conditions and once again go under the sender. And in this case, I want to go down to IP address is in any of these ranges or exactly matches. And as this suggests, we can choose a valid IPv4 address range or just a specific IP address. For example, we can start putting in some IP addresses or we can put in an entire range. And once we hit okay, well, we can once again select our action. In this case, we'll just block and delete the emails. And so you can see here we had three different ways of blocking these sender artifacts based on IPs or domains or even the specific mailbox. And lastly, let's look at another option that we have. If we go to create a new rule, instead of going under the sender, we can go to the subject or body. And here, of course, is where we can match specific subject lines or any phrases included in the body of an email. For example, I'll go to subject includes any of these words. And from here, we can specify words or phrases to match. For example, maybe we've been getting a number of emails with urgent request. and maybe some sort of unique identifier like two exclamation marks at the end. Well, we can add that to our rule here. And of course, we can block the email and click on save. And with this rule enabled, well, we will match any email that comes in that includes the phrase urgent request with two exclamation marks in the subject line of the email. Now, in addition to blocking senders, we also need to consider blocking various web artifacts that we've identified. things like the URLs or the domains associated with fishing emails in their campaigns. And this can be done at the email gateway level to again ensure that we block any emails that arrive with these malicious URLs. But importantly, we can also block URLs and domains at the endpoint level through our EDR tools or even at the network level if we're using an organizationwide web proxy. But with the rise of remote and hybrid work, well, the web proxy example is becoming less common. But there are still ways that organizations can funnel employee traffic through a secure gateway, like using VPNs and blocking URLs at the firewall level. But ultimately, our goal here is to prevent users from accessing malicious links that were contained in fishing emails. And by doing this, we can effectively reduce the risk of compromise and also reduce things like employees falling victim to credential capture techniques. And we can either do this from a specific URL or endpoint level. For example, if a credential capture page is hosted in a specific subdirectory, we can block that whole subdirectory or we can look at more generic domain and subdomain blocks. But again, we need to be very cautious about blocking specific domains and be sure that we conduct thorough analysis and due diligence on the reputation and context around the domain first. Because while this can be a very useful technique if an attacker is using a malicious domain to stage multiple campaigns, for instance, well, it can lead to disaster pretty quickly. For example, you know, it's very easy to block a domain of malicious site.net, but what if you identify a URL that abuses a legitimate service like Google? Well, blocking google.com again is going to be a very bad day for the organization. And so, we always need to gauge and understand the potential business impact by blocking a domain. And so, ask yourself questions like, are employees and executives ever going to need to visit this domain in the future? If not, then you're most likely good to block it. But a URL block is more specific and typically safer from an availability standpoint. For example, what if we wanted to block any email message that contained a specific URL in the body? Well, of course, we could create another rule for this. And in this case, we can look for the condition of specific words in the body of the email. So in this case, I'll select subject or body includes any of these words. And from here, I can put in a URL. Or I could even put in a domain itself. And this will match any email that contains these phrases within the content of the email itself. A good metric that you can use is the age of the domain, which we can find out by doing a domain lookup. You know, for example, has this domain been around for years or decades? Well, if so, then make sure you really do your due diligence on the domain. If it was registered yesterday or last week, then it's most likely a fishing web page that should have already been proactively blocked. And when we talk about proactive methods, well, we'll talk about some strategies to proactively block these domains as well. Just to showcase how we can look up the domain age. Well, I'm just going to find a random URL on this page. For example, let's try this one, shopppeevip.shop. Well, this one sounds like it might have been registered recently. I believe earlier in the course, we actually found a credential capture page that was impersonating this shoppee website. So, it seems to be a popular target for impersonation. I'm just going to head over to the who is domain tools website and I'm going to paste in that domain. And I'm just going to click on search. And from here, we can immediately see under the dates category that this domain is only 2 days old. And we can also see it was registered with godaddy.com. And quite honestly, because of how recent this was registered, it's fairly safe to say that this is a malicious domain that was used to impersonate the shoppee website. And lastly here, we should block file artifacts. And so blocking file artifacts, things like the file name or the hashes associated with malicious files, is another important aspect of fishing incident response. And so by preventing users from downloading or accessing or worse executing malicious files, well, we can mitigate the risk of malware infections and data breaches. And an effective tool that we can use to block file artifacts is to leverage our endpoint security solutions like our EDR to block files based on their attributes like again their name or their hash. And so this is why it's so important for us to extract things like the MD5 or Shaw 1 or SHA 256 hashes from malicious documents so that we can then block these files from appearing within our organization. And so this means that whenever a file with this hash is downloaded or accessed on an employee device, well, the EDR tool will kick in and immediately flag and delete it from the system and also notify the sock. But of course, this is not a foolproof method. Like I mentioned before, hashes are so easy to change and they're so susceptible to change. You know, one slight alteration to a file is going to result in a completely different hash. And this gets kind of into the pyramid of pain, which I'm going to talk about later in the threat intelligence section. And so technically we can also block file names, but often this is not the best method unless the file name is extremely specific or uses a unique identifier for us to alert on. And often there's no reason why we wouldn't just use the hash instead. For example, if we wanted to create a rule around file attachments, well, we can do just that. If we click on create new rule, well, we can select the condition under any attachment. And from here you can see we have various options. For example, we can block any email that might have executable content or is password protected. However, you can see we can also match file names. For example, we can include any email that includes the attachment name of quotation.iso and we can add that to our condition. And so this leads us to eradication. And this is where we're aimed at completely removing all traces of the fishing attack from within our organization. And so of course we want to remove the malicious emails from our email servers. And often we can do this through things like content searches and eiscocovery. And the specific ways and processes to do this is organization and tooling dependent. But we should in theory conduct a comprehensive content search and eiscocovery phase to remove any additional instances of malware content like the fishing emails or attachments that might have been overlooked during our initial detection. I'll quickly demonstrate how we can trace email logs within an Exchange environment. However, I'll mention that more modern solutions like Exchange Online and Google Workspace have much more robust message trace and content search functionality. And so, it's not as important to get hung up on any specific tool that allows you to do this. For example, in a Microsoft 365 environment, we could leverage the security and compliance center or the Microsoft Purview functionality to perform a content search and capture all instances of a malicious email and then purge them using the compliance search purge feature or through PowerShell. and more so we should just focus on the methodology and what our objectives are. Right? We can always look up the documentation if we need it. In this case, I'll just showcase the message tracking feature in Exchange. So, we can first go under the mailflow section and then into the delivery reports tab. And this is quite a limiting feature, but it allows us to search for delivery information about emails sent to or from a specific person. For example, I can specify a mailbox here. Right now, I just have the administrator user. And so I can search for any messages sent to that administrator user. And so I'll just add that there. And then if I just hit search, well, we can see we have two results just from previous testing. Optionally, if we wanted to, we could search for messages from a specific sender. So I could add the administrator here or put in whatever I want, right? So if I run this search, well, we're not going to get anything. But in theory, you could search for a specific email address, right? We could also search for specific subject lines, right? So if I switch this back to administrator, you can see we have two results. But if I search for a specific keyphrase in the subject line like hello, well, we've limited our results to one. So this is not a very in-depth example here, but you can see sort of how we can start narrowing down mailboxes and track specific emails. To gain a bit more flexibility and power, we can use something like the exchange management shell to search for email within our email server using various syntax. And the commandlet that we want to use for this is called get message tracking log. And there are a few parameters that we can use for this command lit like the tax sender or recipients or even with the message subject. So, for example, if I wanted to find all the emails delivered to the administrator user, well, I could simply put in recipients here of that administrator user. And if we run this search, well, you see, we can pull back all of these examples of just test emails that I've sent. If I wanted to find all the emails sent by a particular address, even an external one, well, I can run a similar command, but change this to sender and then put in whatever I want for the email address. And of course, this is not going to return anything in this example. Or if I wanted to search for a specific subject line, I can specify a sender as well as the subject argument and then put in any keywords or phrases that I want. In this case, we'll search for hello again. And you can see we limited our original search down a little bit to only contain messages with that hello in the subject line. And there are of course many other filtering and formatting options that we can apply to only search between specific time ranges or you know other qualifiers for example. But we don't have to turn this into a whole lesson on the get message tracking log feature. And again I'll also point out that this is not the most userfriendly option. And as I mentioned with modern Exchange online environments well we can utilize things like the message trace and content searching features that make it a lot easier for us to find and search for specific emails. And if you're curious about how those tools work, well, you can definitely look up the Microsoft documentation, which I'll have linked down below as well. And I mentioned removing malicious files. So, if there were any attachments that were downloaded or even still in employee mailboxes, well, we need to remove them from these systems and the servers and endpoints. And so, we might need to leverage our EDR tool to quarantine and delete these files. We might need to run PowerShell scripts in our Microsoft Exchange environment to look through our email server and delete all the instances. If the fishing attack involved using malicious domains or URLs to host fishing websites or distribute malware, well, we should always report these domains to relevant authorities and registrers. And by reporting malicious domains, well, it will help further spread an abuse, and the registars themselves may be able to suspend or take down the malicious site. And so, let's return to the domain tools website for that shoppee domain. If we scroll down, you will typically find an abuse contact which we can see under this register abuse contact email. And this specifies the email address where abuse complaints or submissions can go to. Alternatively, since we identified that GoDaddy is the registar here, we can simply do a search to see if they have a public abuse form, which is quite common for large registars. So, I'm just going to look up GoDaddy abuse. And we can see a number of results here. If I just head to this first page, we can see the terms that GoDaddy has around reporting abuse. And if we scroll down, we can see the different types of abuse because they all have different abuse report forms. In this case, we've identified this is a fishing attempt. And we can see all of the required information that's needed to make the report. For example, we need the full domain path, which we found on the fish tank website. And note that in the case of a fishing report, the website must be live and it must contain a login area or a credential capture page. And if we head back over to this URL and paste it into URL scan, we can see that it is in fact hosting some sort of credential capture page which was just cut off in the bottom of this screenshot. And as such, we have all the required information needed to make our report. And if we click on abuse report form here, we'll be taken to the report fishing wizard. And from here, we just need to input our email address as well as paste in the URL entry that we identified. And now we'll be asked for some more information. For example, if we know the brand or company that is being impersonated, we can click yes. And we know that the URL in question is impersonating the legitimate shopppee website. And so I can just paste in the name as well as the legitimate domain. We can also enter some additional information if anything else is required to view the page. In this case, we can just hit next. And in this case, we can provide some more additional information. For example, if we identified this URL in a fishing campaign or any other additional information that might be relevant for GoDaddy to complete their investigation. And once we confirm and submit our report, we can see that our request has been submitted for the following URL. and should any action be taken will most likely get an email at the email address that we specified. And next, as a precautionary measure, it's typically advisable to implement credential changes for any users who might have been affected by the fishing attack. So, we would need to do things like reset passwords and reroll access tokens. And this is especially important if we can confirm that the employee has visited a credential capture page or worse made any kind of post request to one, which we can typically find out through EDR and proxy logs if we have them. Because oftent times we can't just trust an employee to admit that they fell victim to a fish. And no fault of their own, no one really wants to admit that they've fallen victim. And in cases where the endpoints or these systems themselves have been compromised by malware or other malicious activity that we've identified, well, reimaging is most likely necessary to ensure that all traces of the attack are eradicated. And so we're going to need to use things like backup images to restore the system to a known good state, which obviously leads us into recovery where we need to restore the affected systems to normal operations. So again, we might need to restore from backups or reinstall software and implement additional security measures to prevent similar incidents in the future. And so through all stages of our response, well, we need to make sure that we're communicating properly to end users and stakeholders to make sure everyone's informed and to mitigate any potential confusion or misinformation. And so we need to do things like notify the effective users about the fishing incident. So this might involve sending the users an email letting them know that they received a fishing email and provide them a timestamp and description and also let them know what actions we've taken and what we need to take. And so having this clear and concise communication is going to help ensure that all of these users are aware of the situation. And this might also extend to stakeholders like senior management or IT teams. We need to make sure that everyone that might be involved is informed if we need to take specific response actions or schedule certain procedures, but we need to make sure the relevant people are aware. We can also talk about user education because if an employee falls victim to a fish, well, that's kind of on us to make sure that they're properly trained to identify suspicious emails and report them effectively. So, oftent times, organizations will budget for solutions that allow us to enroll employees into security awareness training. And through this training, the goal is to teach employees how to recognize fishing attempts and what to do if they encounter suspicious emails or links and also how to report fishing incidents to the IT or security team. And so while user education is an ongoing and proactive thing, we also have the option of assigning employees remedial training if they were to fall victim to a fish. And speaking of proactive measures, well, let's get into that in the next lesson. Along with our reactive defense actions, well, there are of course more proactive actions that we can also take to help mitigate the risks and impacts of fishing attacks within our organization. And not all these strategies we talk about here will be feasible or available within your organization due to tooling or budget restrictions, but these are just some of the general ideas to keep in mind that can supplement our reactive functions. And so to kick us off here, we have email filtering, which we've talked about quite a bit already. And email filtering is also a foundational proactive defense measure against fishing attacks. And we can do things like automatically detect or block suspicious emails before they reach our end users inboxes. And we can do this either through predefined conditions or rules or by using more advanced threat detection techniques like heruristic analysis or pattern matching, behavioral analysis and even machine learning depending on the solutions that we have. And we covered creating some reactive email filter rules in the previous lesson. But there are tools and solutions that we can leverage to focus on filtering proactively as well. And so we can do this through email security appliances. And so we can think about deploying security applications or tools and various email gateway solutions to proactively prevent fishing emails and malware from entering the organization. And so some of these commercial tools can utilize detection capabilities like the ones we've talked about earlier. So heristic analysis and pattern matching, machine learning, and even threat intelligence to detect and block fishing emails. And these solutions can also do things like scan email attachments and any URLs or links and use signaturebased detection and sandboxing techniques. And some examples of these appliances include things like Barracuda or Proof Point or Mimecast and Semantic. All of these solutions can help provide that multiple layer of fishing detection and mitigation. But we can also consider implementing some proactive efforts to keep employees alert and remind them about the risk of certain senders and emails. And so a very popular way to do this in many organizations is to mark external emails by prepending them with warning messages that can prompt employees to be more aware and more focused when they receive an email from a potentially unknown sender. And so marking external emails can allow users to quickly distinguish between an internal or an external communication. And it can raise that awareness about potential risks associated with emails from unknown senders. And most email server technologies like Microsoft Exchange or 365 and even G Suite environments will have their own specific way to do this. And typically it's just a quick Google search away to find the correct documentation. But let's walk through setting up a simple rule like this in Exchange. So in a Microsoft Exchange environment, we can create a simple mailflow rule to mark external email in the subject line as well as in the body content. So, if we go over to mail flow under our rules tab here, well, we can create a new rule. In this case, I'm going to click on more options. And I'm simply going to call this rule mark external email. And under our condition here, we're going to apply the rule if the sender is external. And so, in this case, we can change this to outside the organization. So currently we're matching any emails that reside from outside of the organization. To be more specific here, we can add a second condition this time under the recipient. And we can make sure that the recipient is internal to the organization. And with these conditions in place, we can create our action. In this case, we're going to prepen the subject of the message simply with the following text to mark it as external. And I'm just going to hit okay there. And I'm going to add a second action now. This time to add a disclaimer to the message. And I want to prepend a disclaimer because I want this to be at the beginning of the email. In this case, I can click on enter text here. And I'm going to paste in this HTML code that is essentially going to create a colored box for us. And inside the box, I'm basically just going to say that this email is from an external sender, prompting employees to be vigilant and not open things like links or attachments without verifying them first. And so I'm just going to click okay there. And then we need to select a fallback action in case the disclaimer can't be inserted. In this case, I'll just set it to ignore. And so I'll save our rule here. And we can now test it out with an external email. And now I'm going to move over to my inbox on Outlook on the web and just wait for an external email to come in. And now that an email's come in, well, we can see the external tag has been automatically prepended to the subject line. And if we were to click on this email to open it, well, we can immediately see this giant red box that we inputed by prepending it to the beginning of our email message. And maybe I could have picked a better styling for this as it's kind of obtrusive and large. Um, but you can sort of see the idea here and how this can be implemented in the real world. And so an employee opening this email, well, we'll immediately be greeted with this warning that, you know, Bob Jones is an external sender and we should be careful about clicking on any links. And so, while we can create our own rule to apply external warnings, more and more email systems and providers are starting to integrate native functionality into their email clients, which we should definitely take advantage of wherever possible. Which brings us to URL scanning and blocking. And as we talked about before, well, URL scanning and blocking mechanisms are very effective in preventing users from accessing malicious websites, linked in fishing emails. And in previous lessons, we discussed reactive methods for blocking URLs and domains after a threat has been identified. But we can also implement proactive strategies as well to prevent users from accessing harmful sites before they cause any damage. And we can do this through things like real-time URL inspection. So through some of our tooling, we might be able to dynamically analyze website links that are embedded in the emails and determine if they're safe or not. Or we can also implement email and endpoint security solutions that can perform things like URL rewriting or redirection. Or we can route any links through a proxy server for inspection before allowing users to access them. And one effective proactive measure is to block access to any recently registered domains. And we demonstrated in the previous lesson on how we can perform lookups on specific domains to find out when they were registered and determine their age. And obviously attackers are typically going to use newly registered domains for their fishing attacks because setting up credible domains and reputation well requires a lot more effort especially when you're constantly being taken down. And so by blocking any domain registered in say the past 30 days, organizations can reduce a huge amount of risk in users accessing malicious sites and also cut down on fishing attacks significantly. And it's pretty rare that there will be a legitimate business purpose to interact with a mailbox attached to a domain that was only registered in the past month. But for these rare cases, well, exclusions and exceptions can easily be made and documented. And like with most strategies we've mentioned so far, various email security appliances and tools are available to implement this kind of enrichment capability that can perform these domain reputation and age checks for us to dynamically filter out the noise. And so we also have things like attachment filtering and attachment filtering plays a crucial role in mitigating fishing attacks that leverage of course malware or malicious attachments. And so in the previous lesson, we talked about some of the methods that we have available to us, such as reactively blocking hashes of known malware or file names. However, we should also think about how we can proactively block malicious attachments from a wider context. For example, what types of files or file extensions will our employees typically need to send over email? Well, most likely it'll be things like PDF documents or Word documents, so doc or doc X or Excel spreadsheets or sometimes image files and maybe zip files. And of course the list can go on. But on the other hand, what types of files or file extensions will they most definitely not need to send? And so we can think about things like executables or VBS, so Visual Basic scripts or any PowerShell scripts like PS1s or ISO files or batch files or ISO files. You know, the list of course goes on. Attackers can also trick people into opening things like HTML or HTM documents or even running JavaScript with.js documents. And to be honest, it's typically better to implement an allow list strategy for specific file types rather than a deny list because the allow list will be much shorter. And so there's going to be many different strategies and opinions on the matter. So it's best you do your own research if you're implementing this kind of thing. So just as a quick example at attachment filtering, well, we can go to our mailflow section and create a new rule. And from here, I'm going to go to more options. And I'm simply going to title this file extension filter. And for our condition, I'm just going to go under any attachment and choose file extension includes these words. And with this window here, we can start to specify specific file extensions that we want to exclude. For example, any executables or Visual Basic scripts or PowerShell scripts, any ISO files or batch files. And so you can see how we can start filling up this rule with either suspicious or non-used file extensions to lower our attack surface and proactively prevent malware from making its way into our users inboxes. And then of course we can select the action. In this case I'll just block the message. We can hit save. And we also have attachment sandboxing. So, some of our security solutions might be able to actually execute suspicious emails in a controlled environment automatically. You know, we talked about how to do this ourselves using some various tools, but in some cases, we can deploy sandboxing solutions that can automatically analyze attachments in a secure environment for us. And let's not forget about email authentication methods. And so, enforcing things like SPF or DKIM or Demar, well, these can all help verify the legitimacy of incoming emails and detect spoofed or forged messages. And so, of course, in the email authentication lesson, we talked about why these technologies are important and how they can be useful in catching spoofing attempts. And so, wherever it's possible and feasible, organizations should configure these authentication protocols to reject emails that fail authentication checks, which of course will reduce the likelihood of successful fishing attacks. And of course, there will always be push back on this strategy because it can result in false positives. But there are also ways and best practices around this. For example, when implementing demark for instance, it's often recommended to start with just a monitor policy, right? So, if we think of the P equals none and we begin monitoring before we start quarantining or rejecting email. And so, this allows the organization to gather data on email sources and authentication issues without immediately going into affecting email delivery. And so, lastly here we can talk about user awareness training. And of course, we talked about user education and awareness training in the previous lesson with the strategy of assigning remedial awareness training to employees who have fallen victim to a fish. However, we can also look at awareness training from a proactive side as well. For example, it's pretty common for organizations to invest in a fishing awareness tool like Novaore or Boson Security or Huntress Sat and many others. And these solutions are often configured to automatically assign and deploy security awareness training to employees or specific departments. And it can be done annually or maybe every 6 months to help build that consistent culture of awareness and reduce the likelihood of social engineering and fishing attacks. And this training is often in the form of short videos or presentations. And it can be paired with things like quizzes or activities to track employee progress and completion which can also help for compliance purposes as well. Additionally, these solutions can also provide the option of simulating fishing attacks within the organization to gauge how susceptible their organization is to these attacks. And so these simulations can help identify which employees are more prone to falling for fishing attempts and also highlight areas where additional training might be necessary. And these simulated attacks are designed to mimic real world scenarios. And so it often includes things like of course email fishing but also fishing and smishing techniques as well. And so by conducting regular fishing simulations while us as a security team can assess the effectiveness of our training program. We can also measure how well employees can recognize and respond to fishing attempts. And we can also provide targeted training to those who need it most. And lastly, it's important to implement methods for employees to easily report suspicious activities to the security team. And of course, this can be done through various means or technical controls to ensure that there is a streamlined and efficient reporting process. For example, it's common to integrate a report fishing button directly into email clients that allows employees to quickly flag suspicious emails with minimal effort. And like with marking external email, well, more and more email clients and email service providers are integrating more native functionality to offer this feature as well. And these fishing reports can often be sent directly to the sock for analysts to be alerted and then investigate the emails to determine their legitimacy. However, I'll mention that reporting should not just be limited to email-based threats. And so organizations need to extend these reporting mechanisms to cover other types of social engineering attacks like smishing or vishing or just essentially any kind of security incident that might be going on. And so there needs to be a clear and defined process for employees to report any suspicious activity that they encounter in their job regardless of the medium. And these reporting methods need to be clear and userfriendly and accessible or else they won't be used. And so this is not an exhaustive list, but hopefully it gives you some ideas on some of the proactive fishing defense measures that organizations implement in the field. As I've mentioned all throughout this section, accurate and thorough documentation is going to be the most important part in your investigation and response to fishing emails. And so strong documentation of course ensures that all actions are tracked and justifies any response actions you've taken. It provides a reference for future incidents and ultimately it aids in the continuous improvement of the sock processes. However, we want to make sure that when we're writing our documentation and updating our tickets, well, we're keeping our notes clear and relevant and concise. And many organizations will have their own templates and possibly even some automated functions to assist in having you write concise and consistent documentation within tickets. So, the exact method you go about this will definitely be something you pick up on the job. However, to prepare you, we can keep things at a high level and keep it more general to make sure you know what is important to include. So, just know that what we'll cover here is just a starting point. You can definitely grow and expand on this as you'd like. And essentially, we can return to the methodology that we outlined earlier in the section to guide us through our documentation. And so as we investigate an email message either through its headers or body content or URLs we identify or attachments well we will of course collect a number of artifacts in the forms of IoC's or indicators of compromise. And we can think of indicators of compromise as any artifact that we observe that will most likely help us with attributing and linking an attack in this case from a fishing email. And so we're definitely going to want to document these IoC's as we find them to fill out a report. And after identifying all these artifacts, we of course want to analyze them and obtain evidence that will support our eventual verdict and conclusion. And after our analysis has been completed, we need to of course give that verdict and document any defensive actions that we've taken or need to take in order to resolve the incident. So to start off, let's head to the fishing analysis folder and then go into tools and finally the report directory. And let's open up sample 1.l. And we'll use this email as our example as we walk through the documentation process. And while we open the email, I'm going to open up the report template.txt file in Sublime Text. This is a sample generic document that I put together that we can use to guide us through the analysis and make sure that we document everything typically required as we work through an alert. And feel free to save this template for your own use. It'll also be included for you under this video as well and it will come in handy during the challenges that are coming up at the end of this section. And so you can see that this template is divided into several sections that will help us systematically analyze the email and any associated artifacts. And so starting off we have this header section where of course we want to document some of the most important headers that will be used in our analysis later on like the timestamp or subject and different things like sender IP. We also of course have a section for URLs and attachments that are involved in the email. Next, we have a section for a description and this is where we can put in a short description of what we find in the body content of the email. For example, what social engineering tactics have we identified or what is the email actually asking us to do. We also want to ensure that we provide detailed notes on all of the analysis actions that we performed such as the sender or URL and attachment reputation checks. This will be the section that supports our verdict from a technical and evidence level and should include screenshots and tool outputs as needed. Under the verdict section, well, this is where we summarize our analysis and determine if the email was in fact malicious or safe to action. And speaking of actions, we have the defense action section where we need to outline what response actions we or the sock need to take both from a reactive and proactive angle. For example, do we need to reactively block a specific sender or URL? Do we need to perform a deeper incident response on any affected users or hosts? Of course, there are so many variables here and they should all be documented in the report. And keep in mind that as I mentioned before, using screenshots is best practice when it comes to documenting tool outputs and findings from our various analyses such as who is lookup results or email authentication checks or virus total and hybrid analysis reports. However, in this case, since I'm just using Sublime Text to demonstrate, well, I'll skip embedding screenshots. But your ticketing system will always have the capacity to accept and upload screenshots to the ticket itself. So, to keep the focus on reporting and documentation rather than analysis, which we've already covered, I'll quickly go through this email and note what I would document as I analyze it. So, first, let's start off with the description, which we can gather by taking a look at the email itself in our client. We can see that it's claiming to be from Amazon Prime support and is asking us to verify our account which has been placed on hold due to a suspicious login. It looks like there are some hints of urgency as our account will be suspended by a specific date if we don't verify our account before then. And obviously this email is a little outdated. It's just an example for this practice section. Well, let's document this information in our report specifically under the description field. And so in this description field here, again, I just want to provide a brief description about what we just talked about. So what is the email asking us to do? What is the context around the email? Are there any specific call to actions that we can identify? Or are there any specific indicators of any social engineering techniques that we've talked about earlier, like urgency or trust or intimidation? Well, we should note these here so we can better understand the content and the context of the email message itself. And so with that out of the way, let's start filling in useful headers that we want to be sure to document. Fortunately, the eioc.py script that I showcased earlier can gather a lot of this information quite quickly for us. And so I'll just run the script here and provide the sample email file. And you can immediately see we've extracted a number of useful headers which matches up quite nicely with our template document. And so I'll just start copying these headers over to our template document. And since there's no reply to header in the original email, well, I'll just take that out from our template for now. We also need to figure out the resolve host. And if you recall, we can do that using the domain tools website or any website that allows us to do a reverse IP lookup. And so I'm just going to paste in the IP address we identified here and click search. And you can see that we've extracted the resolve host or the reverse DNS lookup of that IP address which points to a google.com domain. And so I'll just paste that in here to fill out our headers. And next, in terms of any email authentication checks, it looks like this email was lacking any SPF or DKIM information. However, we did note that the resolved host or the reverse DNS for the original setting email server was a Google address, which is a bit odd from an email claiming to be from Amazon since they typically have their own email infrastructure. Additionally, the return path domain that SPF would object ends in OVH, which is an odd top level domain because that means it's affiliated with OVH cloud, which is a cloud company that offers virtual private servers and other dedicated web services. And so, I'll just make a mental note of that for now. And we don't have any attachments to go off of on this email. So, let's get into URL analysis. And you can see we have quite a number of URLs in this email file. Mostly, it looks like it's linking a lot of external resources like fonts and images. However, what I'm really looking for is the link that we can identify when we hover over the button here. And I can see the domain in the URL begins with cabinet. And so, I can return to our output from eioc.py pi and simply pipe it to the grip command where I can do a search for the word cabinet. And once I do that, we can identify the domain in question, which I'll just copy so we can do a lookup. So, I'm just going to take this domain and paste it into urlcan.io. And I just need to refang it here so URL scan can analyze it correctly. And once our scan finishes, we can see it has been identified with potentially malicious activity. And so I just want to make sure I note this URL and paste it into our template or our report into defang format because it's definitely something useful to us. And I also want to make sure that I take a screenshot of the URL scan output because this is going to become very useful for us when it comes to making our verdict. When we view the screenshot from URL scan, well, it definitely looks like some sort of credential capture page which is impersonating Swiss Pass. It also appears to have redirected us from our original URL to this host domain as identified from the submitted URL versus the effective URL. To make sure we get a second opinion here, I'm going to go over to Virus Total and also paste in the same URL. And once our scan is complete, well, we can identify that seven out of 94 security vendors flag this URL as malicious due to fishing. And so I of course want to get a screenshot of the virus total output as well because this is once again more supporting evidence that this URL is indeed malicious. And so let's start to fill out the analysis section of our report. So let's start with sender analysis. And as we identified, although claiming to be from Amazon Prime, the from address in the header clearly indicates a mailbox originating from an unrelated domain. Additionally, the return path and received headers indicate that this email originated from a google.com mail server and it also utilized OVH cloud hosting, neither of which are typically affiliated with Amazon. And so on to URL analysis. Well, after performing our URL reputation checks using URL scan and virus total, well, the URL within the call to action button of the email was found to be malicious as it redirects to a fishing website. Additionally, it appears to be hosting a credential capture page which we identified through a URL scan. And due to the nature of these pages, we can infer that when submitted, it will log and steal the credentials of any victims. And so with all of this in mind, when it comes to our verdict, well, due to the original sender being unaffiliated with Amazon, well, this email is a clear impersonation and spoofing attempt. And secondly, after analyzing the URL contained in the call to action, well, it was flagged by multiple vendors as malicious. And of course, we want to be sure that we include any screenshots here that we took previously. In this case, since I'm just doing a short example here through Sublime Text, I can't actually insert screenshots. And so to wrap up our report, well, let's think about defense actions. So, what actions do we need to take in order to respond to this fishing incident? Well, first of all, let's say we've done our scope analysis already. And so after performing a message trace, we identified that no other users within the organization received an email from this sender or with a similar subject line. And so because of that, we can move on to reactively blocking the email sender. And so to prevent the malicious sender from sending any other emails to the organization, well, we can identify the email address in the from header. And so we can be sure to and document that we blocked that email address at the email gateway level. And let's also think about the URL that we identified. Well, we want to be sure that we block and also document that we've blocked any incoming emails that contain that URL. Well, we also need to ensure that no employees or users can access that malicious URL either. So, we want to document that we block the domain at the EDR level as well as the web proxy level if applicable. And so, this was just a quick run through to show how we can start filling out this template. And again, just use this as a starting point. When we move on to the challenges in the following lessons, well, you can use this template to guide you during your analysis. And speaking of those challenges, well, I think now is time that we finally get into them. So, join me in the next lesson where we take a look at the first challenge. Now, I definitely encourage you to continue practicing your fishing analysis skills. And so to cap this section off, I wanted to give you three resources that you can use to find additional email samples and URLs and malicious files to investigate. And I'll have links to all these resources down below. And so the first one here is going to be this GitHub repository. And this fishing pot repository here, well, is a collection of real fishing samples that were collected with Honeypot email accounts. And so the purpose of this repository is to provide a reliable database for researchers and students and developers to practice their analysis or to develop detection solutions. And so you can use this resource to look through and download real fishing emails and perform things like header and content analysis to test your skills. So if we just open up the email directory here, well, we can see thousands of sample emails for us to look through. And if you want to download one, well, you can just click on it. And once you have it open, click on the raw view here. And we can just w get this URL. So I'll just open up a terminal and w get that URL. And now we have that sample email for us to look through. So we can open this in Sublime Text, for example, and start going through this email and looking at the headers. And if you really wanted to, well, you could clone the entire repository and get access to every single sample email. And next in the list, what we've of course looked at fish tank before, which is a collection and database of live suspected fishing URLs. And as you've seen me do throughout the course, well, we can use fish tank to perform URL inspection and analysis and test out our tools like URL scan and URL to PNG as well as other web artifact investigation methods. So we can go through any of these URLs here and just click on its ID. And once we have the submission open, well, we can see the full URL here. And in this case, it looks like it's using some sort of URL shortening service. So this is a perfect opportunity for you to use your skills to unshorten this URL and investigate it properly. So fishtank is a fantastic resource if we want to look at URL analysis. And lastly here we have malware bazaar which is a database of malware provided by the threat intelligence community. So if we click on the database here, well we can start to browse through and see some of the malware that has been submitted. In this case, we can see various signatures and tags along with the file type telling us more about what the actual malware is doing. In this case, it looks like we have some macro enabled Excel documents. We also have doc files and executables. And there's actually a search syntax that we can use. So, if we click on search syntax here, well, we can look for specific things. For example, if we were looking for PDFs to analyze, well, we can type in file type with a colon here and then just put in PDF. And once that searches, well, you can see now we're just pulling back PDF files for us to investigate. And if we find a file that we want to analyze, we can click on this link here of the SHA 256 hash. And this will bring us to the specific entry for that malware. And you can see we get a number of different information here. For example, the original file name along with all of the hashes. And if we wanted to download the sample, we can click download sample here. It's going to download in a password protected zip file which is quite standard and also what is quite standard is the password will be infected. So if we click download here well we're going to download that zip file and we can just extract this file by clicking extract here and put in the password infected. And you can see that was successfully extracted into the PDF file. And from here we can start following our file attachment analysis methodology and do things like submitting the hash to virus total or doing dynamic analysis or in the case of a macro enabled word file or excel file. Well, we can start doing some more static analysis if we wanted to. And so I hope you find these three resources useful if you want to get some additional practice in. All righty everyone. Well, I certainly hope you enjoyed that deep dive into well fishing analysis and all the different uh investigative methodologies and tools and procedures and techniques that we have as analysts to diagnose potentially suspicious emails, right? Um, and I will say we did have to cut a few lessons here and there just so we could fit that in along with some of the other domains that we want to cover in this long video. But again, this is my calling here to encourage you uh to check out the full sock 101 course if you are enjoying this content so far. Again, this whole fishing analysis section is just one domain out of I think eight or perhaps nine. And we're always adding uh to the course as well. And so um I would encourage you to check uh check out the TCM Academy. We will have the link down in the description so you can get started in the full sock 101 course. Uh but for now, let's uh sort of move our way over into network security and network traffic analysis. uh which is another extremely important foundational aspect for um not just sock analysts but um sort of anyone in IT or cyber security alike but we're going to learn how we can use tools like TCP dump and wireark uh to capture and analyze uh network traffic in order to find evil or find anomalies or malware going over that sort of network layer uh and also how we can set up rules and detect using things like snort uh or siraata or different IDs and IPS systems. So uh the network security or network traffic analysis section is another big one, another very important one uh and one that I'm really excited for you to jump into. So I will see you over there. Welcome to the network security and network traffic analysis section of this course. And I'm really excited to cover this topic because these concepts are so important and foundational to understanding how interconnected systems operate and how so much of business operations these days relies on being interconnected and networking securely. And so as a sock analyst or even someone just getting into security, well, you'll quickly discover that networking is an essential skill used throughout the sock and within organizations as a whole. And it's going to keep coming up time and time again because so much of IT and security operations are built from it because at its core, networking is the backbone that allows for devices and systems and users to all communicate with each other. And so virtually every asset that we aim to protect, you know, whether it's data or applications or infrastructure, well, it all operates on a network in some capacity. Like unless we're talking about a nuclear power plant's control system or a root certificate authority that's completely airgapped, well, essentially every asset will most likely be connected to a network in some form, whether it be through an internal network or with the wider internet. And so consequently, all of the controls that we implement to secure these assets, well, they will also interact with the network environment as well. And as such, this is also where we're going to find and come across many of our organization's threats. For instance, a sock analyst might need to occasionally investigate in network related alerts that come from things like our IDs or IPS. And these alerts can indicate a wide variety of things, right? Like unauthorized access attempts or unusual traffic patterns or recognized malware communication. And back in the intro section of this course, well, we looked at a sample snort alert and we're going to get more into snort. Of course, in this section, in some cases, a sock analyst might need to actually capture or analyze traffic on a live endpoint to analyze it further and look for malicious activity like command and control communication or drop malware or sensitive information being extracted ultimately with the goal of mitigating potential security threats and analyzing IoC's like IP addresses or domain names or other network and host artifacts. And so let's talk about our objectives for this domain. Well, first we of course want to understand fundamental network security principles. So we're going to look at things like packets and frames and various concepts that make up our network stack and communication channels. So we'll look at common ports and protocols and services as well. And so we want to explore network packets and flows and security controls. And so we'll deep dive into how data is transmitted across networks and various security controls that we can put in place to protect it. And so we'll look at protocols and headers and payloads and different methods for analyzing network statistics. And we also want to develop some hands-on skills in performing live packet captures using various tools. And so we're going to learn how to capture network traffic using tools like wire sharkark and TCP dump. And we'll understand the importance of packet captures and how things like pcaps will assist in our identification and analysis of network related security incidents. And of course once we capture these packets well we want to learn how to investigate them and perform network traffic analysis. And so we'll learn to understand what's going on at the communication level. We'll learn to identify anomalies and intrusions and other potential threats. Right? So we're going to learn to examine the packet content and identify patterns and correlate data to understand the scope of the captured traffic. And so a lot of what we just talked about is focused around network traffic analysis. But we're also going to touch on some network security monitoring concepts as well. And so we're going to learn to configure and manage intrusion detection and prevention systems. Right? We've mentioned IDS and IPS solutions so much already and so it would be a crime not to cover them in detail here and so we'll look at tools like Snort and Siraata and how we can actually deploy these solutions to detect and mitigate network threats in real time. And similarly we'll learn to actually write and implement network prevention and detection rules. And so we'll look at how we can configure the abovementioned solutions to write things like custom detection rules. So we'll look at rule syntax and logic and best practices for writing network monitoring rules. And so that's going to be quite a bit of exciting stuff to cover. And so with that, I will see you in the next lesson where we'll jump right into the fun stuff. If we're going to be analyzing how computers talk to each other, well, we need to make sure we understand how computers talk to each other and how actual data and what we refer to as packets traverse across networks. And this is not going to be a network fundamentals course, as this stuff can easily turn into a 10-hour course alone on networking, which I don't want to do. We'll refresh on some basic networking concepts, particularly as they relate to the sock and incident response activities, but I trust you to understand the most foundational concepts like how IP addresses work, how they're assigned, and things like the OSI or TCP IP model. But ironically, speaking of the TCP IP model, well, let's kind of start with that. Um, let's talk about how different network layer protocols work and how they work together to encapsulate and transmit data across networks. because later on we're going to be looking at packets and doing actual packet capture or pcap analysis. And so I don't want to bore you too much with the highle stuff, but I do think it will be important and beneficial to walk through a quick catch up here before we dive in. And so let's start with a protocol you're most likely familiar with, the internet protocol or IP. And the internet protocol is the fundamental communication protocol that facilitates the transmission of data packets across networks. And so it's kind of that backbone of the internet and it's responsible for addressing and routing packets from its source to destination. And if we are thinking about that OSI model or the open systems interconnection model, well the internet protocol falls into the network layer. And at the heart of the internet protocol is the concept of IP addresses. And you're most likely pretty used to seeing IP addresses now. In fact, we looked at a number of them in the previous section. But an IP address is a unique numerical label assigned to each device connected to a network that uses the internet protocol for its communication. And if we want to get super technical, well, it's a 32-bit binary number uh which is represented in that human readable form, right? So we have a series of four numbers separated by periods. So like 192.168.0.1, right? And IP addresses themselves can be categorized into the two types, right? We have IPv4 and IPv6. And IPv4 addresses are the traditional format that you're used to seeing and are still widely used today. But due to the limited number of IPv4 addresses, remember we think about that 32-bit binary number, we sort of started to make a transition to IPv6 to address the exhaustion of IPv4 addresses and to sort of futureproof the everexpanding internet. But honestly, for the most part, as it stands now, uh you're primarily going to be dealing with IPv4 in the day-to-day still. And we can also think about the concept of IP routing. And this is the process of how data packets are directed from their source to destination across a network. And routing is going to do things like determining the most efficient path for the packets to traverse through the network. And so when a device sends a packet to a destination outside of its local network, well, it's going to be forwarded to a router which is going to examine the packet's destination IP address and basically look into its routing table to determine the next hop along the path to the destination. And that process is going to repeat and continue until the packet finally reaches its destination. And so this kind of brings us to TCP or the transmission control protocol. And this is the other core communication protocol within the TC IP suite. And it kind of provides that reliable connectionoriented communication between devices over a network. And it operates at the transport layer of that OSI model and kind of sits on top of the internet protocol layer. And so when we think about the TCP protocol, well, the word I want you to remember is reliable. And so TCP establishes a reliable communication channel between devices by using various mechanisms like acknowledgement flags and sequence numbers. And so when a device sends data over a TCP connection, well, the receiving device is going to acknowledge the receipt of each packet by sending back an acknowledgement packet themselves. And if the sender does not receive that acknowledgement within a specified time frame, well, it's going to retransmit the data packet to ensure that it's delivered. And it can do this because it assigns things like sequence numbers to each packet and allows the receiving device to reorder and reassemble packets to the correct sequence as needed. And we also think about how it's described as this connectionoriented protocol. And so it employs this magic thing that we call the three-way handshake that we'll cover later to basically establish a connection between devices. And it can also implement things like flow control and congestion avoidance mechanisms to regulate the flow of data and prevent network congestion. And we also have the concept of multipplexing and demultiplexing of data streams which sounds pretty high level and complex but basically you know we can think about using port numbers to identify different communication channels within a single TCP connection right so each TCP segment contains port numbers to both the source and the destination devices which allows for multiple concurrent connections to coexist on the same network interface and we'll touch on this a bit more later and so lastly this brings us to UDP or the user datagramgram protocol And this is a connectionless communication protocol, right? So unlike with TCP, well, UDP does not provide any reliability or sequencing of data transmission. Instead, it can offer things like a lightweight and best effort delivery mechanism that's more suitable for applications where speed and simplicity are prioritized over reliability. And so when we call it an unreliable protocol, well, it kind of carries a negative connotation. But really, all it means is that there's no guaranteed delivery or sequencing of the datagramgrams themselves, right? So there's no acknowledgement or sequence numbers and so it's more susceptible to packet loss or duplication or out of order delivery. And while it kind of seems like a drawback, well it it makes up for itself with higher performance and lower overhead compared to TCP. And so we can think of very common use cases, right? So voice over IP or anything when we're streaming, right? So streaming media like videos or audio or online gaming, you know, any of these scenarios where the real-time communication and low latency is more important than, you know, the reliability of the connection. And so, as we've covered at a high level what each of these protocols do, well, let's look at the logical makeup and the standards behind these protocols specifically through their headers. And a protocol header is a structured section at the beginning of each data packet that contains various metadata and control information that's necessary for the transmission and interpretation of the data being sent. And so, let's start off by taking a look at the typical IPv4 header. And as we start going through this, well, you might be thinking like, whoa, there's a lot of sections here. Why is networking so unnecessarily complicated? Well, let's quickly go through some of these uh sections to get a general idea of what makes up this header. And so, we have things like the version of the IP. We have the header length and the type of service, which is sometimes used for quality of service parameters, but in in most cases now, it's kind of just for packet priority and handling. We also have the total length, right? So, including both the header and the data that's appended to it. We have different flags that can be used for controlling or identifying fragments. We have the time to live which kind of represents the maximum number of hops or routers that a packet can traverse before being discarded. Right? And so there's a lot here and I went through it kind of quickly on purpose because yeah, this is great and all right, but how does a system actually know where to send a packet or data? And how does the receiver know where to send the replies to? Well, there are two main pieces to this header that we really only need to focus on from a practicality standpoint. Like to be honest, we can pretty much abstract the majority of this graphic. So you don't need to memorize this at all. It's rarely going to come into play in your day-to-day. So we can tune our focus to these middle two headers. Right? So we have the source address which specifies the IP address of the packet sender and of course the destination address which specifies the IP address on the packet's intended recipient. Right? So we can think of mailing an actual letter if if that's even relevant anymore. So, you would jot down the recipient or the destination of your mail on the front of the envelope. And you would also put a return address or the source address to say who it's from. And so with these two headers, the sender and receiver are identified within the packet itself. And our appliances like routers will perform the magic of examining these addresses to determine the best path for the packet to reach its destination. And this is how the internet works, right? It it doesn't work through domain names. We use DNS to translate domain names that are more friendly and things that we can remember like google.com into an actual internet protocol address. So we can demonstrate this really quickly, right? So let's say we wanted to check the availability of tcmssec.com. Well, we can use the ping command and simply type in tcmssec.com. And so if I run that and immediately stop, well, we can see right away that the tcms domain was resolved into this number or this IP address, right? So through DNS, this friendly domain name was transformed into this IP address that can then be used for routing over the network layer using the IP protocol. And if we just do an NS lookup with the type of A, which is the address record, and it's the type of DNS record that is used to map a domain to the corresponding IPv4 address, right? And if we just put in TCM sec.com, well, we can get the same IP address here, right? So in simpler terms, it translated the human readable domain into a machine readable IP address like 190.92.188.190. And yes, that's how DNS works. And I'm sure I'm sure this isn't the first time you're seeing this. And so it's great that we know where to send packets to and where we'll be receiving packets from, but we didn't touch on anything related to ports and protocols with IP, right? And so let's return to the TCP protocol again and take a look at its header. And remember we have the IP protocol and what can sit on top of that is TCP and the IP header gives us that highle indication of the direction of travel right so it basically says go to this destination IP address or this packet came from this source IP address and so when we get into a more session layer protocol like TCP well we're talking about things like making reliable connections between parties and doing things like network address translation or having multiple connections made on one system and so obviously a big thing with TCP are ports And you can see we have 16 bits separated for the source port and 16 bits for the destination port. And because of that, that's why we end up with 65,535 available ports out there. And that kind of brings us to the topic of ephemeral or highle ports. Right? And so on the server side, we typically have some well-known and established or standardized recommendations through various RFC's that dictate which port numbers should relate to which service, right? So we can think of FTP on port 21 or HTTPS on port 443. Well, we also have this concept of dynamic highle ports that get assigned by operating systems to facilitate the communication between client and server. And so when a client application initiates a connection request to a server, it will typically select a random highle port from a range specified by the operating system. And this is the port that will serve as the source port for the connection. And so when the server receives this packet, well, the server has already allocated its own well-known port known as the destination port that corresponds to the service that the server is providing like port 80 for HTTP for example. And the server will select the client's highle port or the ephemeral port to be the destination port in the response. And so by using these ephemeral ports, well, it's essential basically for enabling multi-client server connections simultaneously and ensuring that each connection is distinct and identifiable, right? So you can think about having multiple browser tabs open. So each connection to a different website is using port 443 in most cases, but they use different highle ports to differentiate the communication. For example, google.com might be using port 54321 and amazon.com might be using port 45535, right? It doesn't really matter. They're highle random ports. And so within the TCP header, right, we have the source port and the destination port. We also have something called the sequence number. And this is a field that's used to specify the sequence number of the first datab in the segments data. And it helps in ordering and reassembling segments at the receivers's end. And so it really comes into play with this whole idea of reliable and connectionoriented delivery. And so when a TCP connection is established, well, each bite of data that's sent over the connection is assigned a sequence number. And because TCP guarantees the ordered delivery of data, well, these sequence numbers allow a receiver to reassemble the received data in the correct order, right? So if any segments arrive out of order, well, TCP can use these sequence numbers to rebuild and reorder them before delivering the data to the application. And we also have an acknowledgement number. And so if the acknowledgement flag is set, which we'll get into, well, this field will contain the value of the next sequence number that the sender of the segment is expecting to receive. So this is kind of how we can get in sync between client and server. We also have things like a data offset. We have some reserved bits for future use. Um as well as many different flags. And so there are a number of flags, but the main ones that we can focus on are like the acknowledgement. And so when the acknowledgement flag is set, well, it's used to acknowledge the receipt of data. And so every TCP segment after the initial three-way handshake, which we'll talk about soon, is going to have this flag set. We also have things like the reset flag. So if anything like I said gets out of sync or out of order or if a packet arrives unexpectedly well it's able to sort of reset the process and the communication. And then as I mentioned we have that sin flag which is used during the initial steps of establishing that TCP connection. And we also have a fin flag which is used to indicate that the sender has finished sending data and so it's part of the termination process of a connection. And again there are some more uh bits here like the window size. So this kind of specifies the receive window which is the number of bytes that the sender of the segment is currently willing to receive and different operating systems have different window sizes which you can look up but ultimately it helps with that sort of flow control right and along with flow control we have error checking which we can do through a check sum and if these check sums don't match well we can tell something went wrong we have an urgent pointer which is kind of only set if the urgent flag is set which we don't really need to get into at this point um and then we also have options and padding which is kind of more variable able and optional. And again, these aren't super important to understanding the entire concept. And so, the main things we want to focus on in this header, well, are the ports, right? The source port, the destination port along with the sequence and acknowledgement numbers as well, and also any flags that are set, which we can talk about in a little bit as well. And so with a UDP header, it's very different and it's much shorter as you can tell, right? So, we have the source port, we have the destination port, we have a length, and at the end we have a check sum. And so you can see we don't have any indications of reliability or state here, right? There are no acknowledgements. There are no sequence numbers. There are no flags. And ultimately there's no handshake, right? It's just basically throwing packets and hoping that they're delivered. It doesn't care if they made it. There's no retries. There's no reyncs. It just throws stuff over the network. And again, this works great for video and audio, right? If you drop or miss some packets, it's not going to be a huge deal. The reliability and integrity doesn't need to be onetoone. you know, we can have a slight glitch or hiccup without affecting the overall user experience. And so, let's talk a bit about TCP. Again, I mentioned this concept of the three-way handshake. And so, remember how we said TCP is a connectionoriented protocol and that it's reliable? Well, the TCP 3-way handshake is the underlying process that establishes a reliable connection between two devices over a network. And it's that sort of fundamental part of how data is exchanged through the TCP protocol. As the name suggests, there are three steps to this. And so we can start with the first step, which is the SIN or the synchronization. And so client A in this case is going to initiate the connection by sending a SIN segment over to server B. And this segment contains the initial sequence number, which is a random value that client A chooses, right? And so this is used to start the sequence for data transmission. But after receiving the sin segment from client A, well, server B is going to acknowledge the request by sending its own sin segment back to client A. Right? So in addition to the sin flag that's checked, well, this segment is also going to contain an act or an acknowledgement flag to acknowledge the receipt of the initial SIN segment. And so the acknowledgement number that server B sends back in the segment is going to be set to the original sequence number that client A sent incremented by one. And lastly here, again this is only three steps. And so client A is going to acknowledge the SIN act from server B by sending just an act back to server B. And so this is once again going to confirm the receipt of server B's sin segment and complete the handshake. And the acknowledgement number in this case is going to be set to the sequence number received by server B. And at this point you can guess incremented by one. And so now both client A and server B have synchronized their sequence numbers and can start exchanging data reliably. And so enough PowerPoint for a second. Let's try to demonstrate this at a very basic level. And if you want you can follow along. And so I'm just going to open up the terminal. And what I'm going to do is just hit control shift and t twice so I can open up two more tabs of terminals. Right? So we have three here. And in this case, I'm going to use the netcat utility, which is a computer networking utility that can read and write from network connections using both TCP and UDP. And I'm going to set up a listening server just on my local host. And so I can do that with the simple NC command. And I can provide various options like L here to listen. I can do tac V here to make it more verbose. So we can actually get some output. And with the TAC P, I can specify the port that I want to listen on. In this case, I'll just choose 1 2 3 4. And I know there are some people out there that have used netcap before and are probably internally yelling at me uh for not uh combining these arguments into a single one. Right? So what we can do is just do attack LVP and that's going to both listen as well as set the verbose option and also specify the port. Right? So we can just run this. And you can see there that we're listening on 0.0.0.0 which is our internal local host address on port 1234. And so on this second tab here, well, I'm going to act as if the client in this model, right? So if we think of this as the server that's listening for the connection, well, this will be our client. And in this case, I'm going to run netcat again, and I'm going to specify my local host. And so if we think about DNS quickly, well, I can just type local host, right? And that's going to resolve to this specific local host IP address. And how does our system know to do that, right? Well, we can take a look at what's called the Etsy host file. And this is a file on Linux. There's also a version on Windows as well, which kind of provides a local list of DNS names to resolve, right? So, if I just do cat Etsy host, well, we can see that local host here, we can think of this as a domain name. This resolves to 127.0.0.1. So, we can use either, right? We can use local host or the IP address. It doesn't really matter. And then, if you remember, the port that we're listening on is 1 2 3 4. And I'm just going to provide tac v there to make it verbose. So we can see the connection being made. Right? So you can see immediately we have a connection over that port. We can see it was successful. If we hop back over to our server, well, we can see that the connection was received. And look at this. What does that look like to you? Well, that is an ephemeral port. It is that highle port that the operating system randomly chose and assigns it to that basically ephemeral high port. And now I can start doing things like saying hello, right? So I just sent over a hello message. If I go back to the client, well, we can see that right there. I can reply and we can see that it's being sent over this connection. So that's cool and all. Um, let's do this again. So I'm going to set up my listener. I'm going to have my connection or my client ready. But in this case, I'm going to first set up what is called TCP dump. And TCP dump, which we're actually going to cover pretty shortly, is a command line network packet analyzer tool that we can use basically to analyze the packets that are traversing through our little network that we're making up, right? And we can do this by specifying TAC I here to indicate the interface we want to use. And I'm just going to type L for our loop back address because remember we're all doing this on our local host. And so if I hit run here, well, got to type in my password. You can see we're listening on this interface now. And so now when I make the connection, well, let's hop back over. We can see some interesting things that were logged, right? So we can see another highle port that was specified on the verbose output here on the server. Well, if we go over to our TCP dump output, well, let's take a look at this first line here. We can see local host, which matches up. This is our highle or our ephemeral port that is making the connection. We can see where this little arrow is pointing to our server on port 1 2 3 4. And when we look at what flags were set, well, we can see this S here for the SIN. And we can also see the sequence number, right? So this is that built-in state within the connection. And so when we look at the second line here, well, we can see it's coming from the server on 1 2 3 4 going back to localhost on 36838. And we can see in this case in terms of flags, we had sin and then this dot here which refers to act. So we have sin act. This is that second stage in the handshake. And we have our own sequence number here. And if we look at the acknowledgement number, well, does this look familiar? Kind of. It's the original sequence number incremented by one. Right? That's what we covered. That's what we talked about. That's expected to happen. And lastly, here we can see the final act based on the flag sent from the client to the server. And if we start sending a bunch more uh let's go to the client here. If we start sending a bunch more messages. Whoops. Hi. Hi. Hi. Hi. Hi. and head back over. Well, we can see a number of acts, right? So, we talked about how after that handshake is established, well, we're basically just getting axe until the connection is terminated. And so, we can see all of these different acts and we're getting some push flags here as you can see by the capital P. That's basically just netcat saying don't fill up the TCP buffer with these packets, just send them through. And so, finally, let's terminate our connection. So, this is our client here. I'm just going to c to cancel out or close our connection. And if we head back over, well, we can see the connection was closed with these capital F or the FIN flag. So, it's pretty interesting how we can see all of this happen. I'm just going to set this up again. And let's think about the ping command again. And if I just ping myself on 127.0.0.1. All right. So, I'll send some pings over and head back over. Well, we can see that this output looks totally different. Well, that's because we're using a completely different protocol here, right? So, ping uses ICMP or the internet control message protocol. And so, in ICMP packets, well, unlike TCP packets, we don't have flags or options like we did with TCP. And so, if someone ever asks you what port ping uses, well, they just think they're cool and they're trying to trick you with a trick question. So, the fact is ping doesn't use ports at all. ICMP basically sits on top of the IP address. Speaking of ports, um, as sock analysts, we're going to often investigate network captures that include evidence of interactions with various ports across the network. And so understanding the common ports and protocols is going to be really useful for us for recognizing and analyzing network traffic, right? So we have the concept of well-known ports like HTTP on port 80 or HTTPS on port 443. Well, the other thing here is that services can technically run on any port. So, we can't always make assumptions based solely on the port number. And so, you're not expected to immediately memorize all of the common ports out there, but over time, it will become more natural for you to associate certain port numbers with their typical protocol. And if you ever come across something you're unsure of, well, the answer can be found a quick Google search away. And so, I'm going to cover what I think will be the most useful ports that you'll see come up in the field. But this, of course, is not going to be an exhaustive list. As as we mentioned, there are 65,535 ports out there. And we're obviously not going to cover each one. And we also don't have to go into, you know, great detail on each port and protocol here. It's more so going to be a general list because we're going to get into some specific protocols in more detail as we actually frame network traffic analysis within the lens of incident response. And so to compile our list here, I'm just referencing the top ports that NAPAP, which is a popular network port scanning tool, uses to prioritize based on how common these ports are in the wild with some slight modifications. And so we can start with port 21 which is FTP or the file transfer protocol. And FTP is used for transferring files between a client and server over the network. And so it works by establishing a connection between two devices. And from that established connection, files can be downloaded and uploaded as needed. So next we have port 22 or SSH or secure shell. And SSH provides secure remote access and management capabilities to servers and clients and allows users to securely log into a remote system over the network. And because it's encrypted, well, it's very useful and secure from a confidentiality and integrity point. And so the protocol itself is often used for various purposes like most commonly with shell sessions. But we can also integrate it within FTP itself, right? So we can have a secure file transfer protocol. On port 23, we have TNET, which you can think of similar to SSH except it's not secure is I guess the highle way to put it. And so it's used typically for remote terminal access and management of network devices similar to SSH. But it's considered insecure because it transmits data like things like login credentials in plain text. So if someone's eavesdropping or listening to the network traffic, well they can sniff out credentials quite trivially. On port 25, well we covered this. This is the simple mail transfer protocol or SMTP. And it of course handles the transmission of outgoing mail from email clients to other email servers. On port 53, well, we talked about DNS or the domain name system, right? And so DNS resolves domain names to IP addresses or in the case of a reverse DNS vice versa. And it enables users to access resources on the internet using human readable names. On port 80 that is HTTP or the hypertext transfer protocol. And HTTP is the default protocol for unencrypted HTTP connections. So web browsers can communicate with web servers and request web pages and receive HTML content and images all without any encryption. And this was the standard up until about uh I don't know the mid2010s maybe until HTTPS really dominated and took over. On port 110 we have POP 3 or the post office protocol 3 which again we covered. And so this is used for retrieving emails from a mail server to a client device. On port 135 we have Microsoft remote procedure call or RPC. And this is a protocol, as you can tell, used by Microsoft Windows um for communication between processes or interprocess communication. And so it uses things like the RPC endpoint mapper service, which dynamically assigns ports for other RPC services. And so again, it can do things like interprocess communication, but also allow for things like remote administration tasks in Windows environments. On port 139, we have net bios session service. And so net bios or networkbasic input output system provides services related to the sharing of resources and communications between devices on a local area network or a LAN. And so port 139 is used by net bios to establish sessions between devices. And it can enable things like file and printer sharing and name resolution within Windowsbased networks. On port 143, another one we covered already, IMAP or the internet message access protocol. And it's used again for accessing and managing email services stored on a remote mail server. And if you remember, IMAP has a little bit more features than uh something like POP 3 or the post office protocol 3 and is more commonly used nowadays. On port 389, we have LDAP or the lightweight directory access protocol. And LDAP is a protocol used for accessing and managing directory information services such as user authentication or doing things like directory lookups. And so often we associate it with Microsoft's active directory and is commonly used within AD environments, but it's also a more just in general directory service as well. So on port 443, well that is what you are on right now to watch this video. And that is the hypertext transfer protocol secure. And so it's just like HTTP on port 80 except it includes TLS encryption within the connection to secure data transmission and ensure things like the confidentiality of things like user credentials or financial transactions over the web. On port 445 we have SMB or server message block. And it's a network protocol used for file sharing and printer sharing as well as other communication between devices on a network. And again it's commonly associated with Windows systems. And it can enable devices on the network to access shared resources again like files or printers and perform various network related tasks like authentication and also remote administration as well. Okay, we're almost there. Port 3389 is the remote desktop protocol or RDP. And RDP allows users to remotely access and control a computer or a server over a network. Right? So it can actually transmit desktop graphics and keyboard and mouse inputs between the client and remote host all over the network. And so if you've ever remoted into a system and had access to a guey or graphical environment, well, chances are if it was a Windows system, especially you were using remote desktop protocol on port 3389. And lastly here we have port 8080, which again refers to in most cases hypertext transfer protocol. Again, none of these ports have to match up with these protocols, right? We're just going based off the standards and RFC's. This is a common alternative to port 80, and you'll commonly see it used in development servers, right? So if a developer is standing up a quick server to test something or run something or in the case of proxies where you're actually proxying traffic without conflicting with any other services. And so that was this is a big list, right? And you don't need to memorize all of these numbers. But over time as you start doing more analysis and you start looking at more evidence and doing your own research, well you're going to start slowly associating protocols with their ports. And we also covered quite a bit in this lesson as well. And so take a breath, take a breather, and I'll see you in the next video where we will continue. When it comes to network traffic analysis, there are countless different approaches and strategies to determine the best way to collect and detect and analyze network data. And so in this lesson, we'll talk about two highle approaches to capturing and storing network data and how they're often opposed to each other, but in reality, they kind of complement each other very well and serve their own purpose in the grand scheme of network traffic analysis. And these two approaches are packet- based analysis and flow-based analysis. So first let's talk about what is a packet right? So a network packet is a unit of data that is transmitted between devices over a network. And so it contains both the actual data being transmitted in the form of a payload and also the control information or the metadata that's used for routing and managing the packet as it traverses the network. Specifically though, we can think of packets as a single piece of an entire puzzle that we want to send over a network. For example, when retrieving a web page over the internet, well, the entire web page can't be sent over in a single piece. Instead, it's broken down into packets of data and sent over the network to be reassembled on the client's end to make up the full web page. So to put it another way, packets allow systems to transmit data efficiently over the wire by breaking it down into smaller chunks that can be routed independently and reassembled at the destination. And typically a packet is made up of three main parts. First we have the header. And if you recall in the last lesson, we talked about various packet headers in great detail. And so packet headers are the important part of network packets that contain all of the information and metadata required to direct the packet during its transmission and its handling across the network. And if you recall, we talked about the IP header and how it will contain a source and destination address to ensure that the packet can route between sender and receiver. We also looked at TCP and UDP headers. Specifically, the TCP header, we looked at things like the source and the destination port along with the sequence and acknowledgement numbers. So as a TCP IP packet traverses across the network, well, it goes under a process of encapsulation with the TCP header encapsulated within the IP packet. The IP header is then added to the front of the TCP segment. And so upon reaching the destination device, the IP packet is received and processed. The destination device determines the IP header to determine if the packet is destined for itself. If so, the IP header is removed and the encapsulated TCP segment will be extracted through a process of de-incapsulation. And this encapsulation and de-incapsulation will continue as the data traverses through the different layers within the TCP IP model. And so beyond the headers lies the payload and this is the core content of the network packet itself. And so the payload contains the actual data being transmitted from the source to destination. And this data can vary widely depending on the application or the protocol that generated the packet. Right? So in the case of web browsing, well the payload might contain the HTML, the CSS and the JavaScript or other content that makes up the web page. If it's an email communication, well maybe the payload would include the body of the email message. In the case of FTP or the file transfer protocol, well the payload might encompass the content of the actual file being transferred. And also depending on the application and source of the packet, the data within the payload could be encrypted, which of course is a good security practice, meaning that if the packet is intercepted by any unauthorized parties, well, the data within it will remain secure and confidential. However, for us as sock analysts, well, this encryption can also add a bit of overhead and complexity when it comes to actually monitoring and analyzing the data within the payload. And lastly here, following the payload, some network protocols will include a trailer or a footer section at the end of the packet. And while not all protocols incorporate a trailer, those that do will typically use it for a specific purpose like a check sum or error detection or data integrity. In some cases, the trailer or footer might be used for padding purposes where it will add extra bits of data to the end of the packet to ensure that it meets a minimum size requirement specified by the protocol. An IP packet, for example, does not contain a trailer, but Ethernet frames, for example, do. And so when we think about the process of performing packet captures, this is going to involve intercepting data packets as they traverse across the network. And once these packets are captured, well, they can be stored for further processing and analysis. And this can become very useful in an incident response scenario. And there are many methods and strategies for capturing network packets. And each of them have their own advantages and use cases. So for example, we have the concept of port mirroring or using span ports. And this involves configuring a network switch to copy traffic from one or more ports or VLANs and send it to another designated port for analysis. And so by doing this we can monitor the network traffic without interrupting the normal network flow. We also have solutions in the form of inline network devices such as IDS or IPS systems which can capture and analyze packets as they pass through. So these devices would be placed directly within the network path and can take action on packets based on predefined rules. And we also have network taps and these are physical devices that are connected to network cables that can passively capture the traffic. And so these provide more of a non-intrusive way to monitor the network traffic. And each of these methods have their own considerations in terms of cost and complexity and also scalability. And so the choice of method will depend on specific requirements of the network and the goals of the organization. We talked about logging and storing packet captures. Well, typically this is going to be done through the use of packet capture or pcap files that store these packets for detailed inspection. And so a pcap file is a binary file format that's used to store network packet data that's been captured during network traffic analysis. Each packet in a pcap file typically includes the raw binary data of the packet itself along with any metadata such as timestamps or packet lengths and possibly other information depending on the capture tool that was used. And when we're going through the process to collect pcaps that contain all of this network data, so including both the packet headers and payloads or all of the ones and zeros, we typically refer to this as a full packet capture. And once we've collected the pcap files, we can leverage tools like wireark, which can provide a graphical interface to analyze the pcap files and allow us to dissect and filter packets in more detail to identify anomalies and malicious activity. We can also use command line tools like TCP dump to analyze pcaps much more quickly and at a larger scale. And we're going to cover both of these methods in the following lessons. And so, as mentioned, a full packet capture is going to be the most useful method for us as analysts when it comes to incident response since it captures every single bit of data and provides the most detailed record of network activity. And with this detail, we can inspect the packet payloads to understand the specific protocols and applications being used. We can potentially look at things like files being accessed or requests that were made or authentication attempts and much more. However, this level of detail is also part of its drawback. And so this type of capture is going to be quite resource inensive in terms of both network bandwidth and storage space. So capturing every packet that traverses the network can quickly generate a large amount of data requiring a lot of storage capacity and network bandwidth for both capturing and analyzing the traffic. And also this kind of thing can potentially raise privacy and legal concerns as it might capture sensitive information like user credentials or personal communications and other proprietary data. So there are often considerations and potential restrictions on what can be captured and how long it can be stored. So it's important for organizations at a high level to consider these factors and ensure that they're compliant. On the other hand, there is a more macroscopic or zoomed out approach to capturing network data using flow records and specifically we can talk about net flow. And so net flow is a type of network protocol developed by Cisco for collecting IP traffic information and monitoring network traffic. And it works by collecting and aggregating metadata about the network traffic flows such as the source and destination IP addresses or the ports and the protocols and timestamps without capturing the full packet contents and specifically a flow record can be identified by the standard five tpple. So that would contain the source IP address, the source port, the destination IP address, the destination port along with the transport protocol. For example, net flow specifically defines a flow that shares seven values. So it includes a few more than we mentioned here which we don't really need to get into at this stage. We can think of the comparison here almost like reviewing the transaction logs on a cell phone bill. Right? So flow records or net flow will act like a summary on the phone bill and provide an overview of you know who called whom, when the call occurred, what was the timestamp of the calls and for how long did they last so the duration and this will give us a bird's eye view and allow us to grasp the broad patterns and trends in the communication. On the other hand, pcaps or packet captures go much deeper and capture every packet exchanged during the conversation. So this would be similar to not only having a phone bill with the summary of call transactions, but also having a full voice recording of what was said over the phone. Is this the Krusty Krab? And so flow data is typically generated by network devices like routers and switches and firewalls which can export flow records to a net flow collector for analysis. And these flow records can provide us insights into network traffic patterns and allow us to identify trends and detect anomalous behavior. So one of the key advantages to net flow or flow records is its efficiency in terms of network bandwidth and storage requirements. So unlike full packet captures which can generate large volumes of data, well net flow data consists of a compact flow record that can summarize network activity and it's much smaller and much more efficient and much more scalable. And so it makes it much more suited for continuous monitoring purposes without placing a significant burden on network resources. And because the records are much smaller, well they can be stored for much longer as well. I mentioned earlier that there are other standards or protocols than just net flow. There are a number of similar network flow protocols like JFlow, Sflow, Appflow, IP fix, and various others that initially stem from Cisco's efforts. But because of the desire of other vendors to avoid relying solely on Cisco technologies, well, this is why a number of alternative standards have emerged. And so we can use a comprehensive tool set like SILK, which stands for the system for internet level knowledge, to collect and process net flow and other types of flow data. And we can use the silk suite to filter and aggregate and analyze the data no matter what proprietary means it came from or was generated from. But again on the other hand because net flow data lacks that payload detail it doesn't really give you the full picture compared to pcaps. And so while a lot of people will frame the conversation as if you can only have one or the other within a sock environment. Both packet-based and flow-based analyses support each other and play complimentary roles in maintaining network security. And so analysts can typically use flow-based analysis to monitor highle traffic patterns and detect anomalies or suspicious behaviors. And once an anomaly is identified or detected, well, they can then capture and examine the full packets to correspond to the suspicious activity for a more detailed inspection. Right? So pcaps might be more suitable when investigating a known bad system or a network segment where the depth of the detail provided by the full packet capture is necessary for thorough analysis. On the other hand, flow records are better suited for continuous monitoring and should ideally be deployed more near the edge of the network to watch for specific activity on a day-to-day basis. And so with all of that, we're now going to jump right into some hands-on with performing full packet capture and analysis using various tools in the following lessons. Let's take a look at one of the most widely used and efficient ways to capture and analyze packets from the command line, the TCP dump utility. TCP dump is a powerful command line packet analyzer that allows us to intercept and display packets being transmitted over a network and with TCP dump we can perform many of the powerful functions that we can get in a graphical user interface like wireark but with greater versatility and advantage of being easily scriptable. However, both TCP dump and wireark have their own strengths and weaknesses which we'll talk about when we get to the wireark section. And so while command line tools can be less userfriendly compared to GUIs or graphical user interfaces, they offer more advantages in terms of speed and scriptability and scalability and also the ability to run it in a headless format without needing a GUI. And there's a similar program on Windows called Windump, which offers much of the same functionality, but in this lesson, we'll focus on the more ubiquitous TCP dump. And ubiquity is an important part here because TCP dump is available on almost all Unix like operating systems making it a useful tool in our sock analyst toolkit particularly during instant response scenarios. And so like I said it's typically already installed on your distribution. But for the chance you need to install it well we can just run pseudoappget install TCP dump and just type in your password there. But you can see we already have it installed on the lab machine. And so with TCP dump, which we'll get into, well, we can capture packets traversing any of the network interfaces on our system. We can also apply complex filters to capture only specified packets based on their protocols or IP addresses or even ports and TCP flags. And we can decode packets and display their content in a more human readable format as well. And with this, we can also do what's called offline analysis as well because we can save captured packets to a pcap file for later examination. The pcap files that we save through TCP dump can also be analyzed through any other tool that supports the format like wireark which provides us again more flexibility in how we want to approach our packet analysis and response. And so common use cases you'll see with TCP dump are things like spanport monitoring, right? So we can set up TCB dump to capture traffic from a span or a switchport analyzer on a network switch. And this will allow us to monitor all of the traffic that passes through the switch and give us more comprehensive visibility into our network activity. Or we can do things like remote packet captures, right? So we can remote into a server or workstation. And we can use the TCP dump utility to capture packets directly on the server or the workstation without even needing access to the GUI. And we can also do things with scripts, right? So we can easily integrate scripts to automate packet capture and analysis. So we might want to set up some automated captures during specific times or triggers based on certain network events. And so let's get into it here. The first thing I'll mention here is that TCP dump interacts directly with network interfaces to capture its packets. And it does this by accessing low-level network resources within the operating system. And so because of this, these actions are going to require elevated permissions to ensure that only authorized users can interact with the OS at this level and intercept and analyze network traffic. And so because of this, TCP dump typically needs to be run with root permissions if we're doing things like capturing packets. And that can be done quite simply by prepending the pseudo command or the super user do before the TCP dump command to execute it as a super user or root. Right? So if I just type who am I? Well, I am not the root user. And so if I just type TCP dump and try to monitor on my loop back interface, well you can see we don't have permission to perform that action. However, if I run the same command but prepend the pseudo command in front of it, well I can run this as pseudo. And if you haven't typed in your password already, you'll need to at this point. But I already have. In fact, I can demonstrate that in a new tab. So, you can see it's requiring our password, but now we're listening. And so, all of the commands that we're going to use are going to involve quite a simple command syntax. And that's going to be pseudo TCP dump. And then we can provide any options that we want. For example, we could specify a specific interface with TAC I and then provide the name of the interface. Or we can specify specific capture filters, which we're going to get into shortly. And each option we provide will of course require an expression or a value such as the actual interface we're listening on or an IP address that we're filtering on. But again, we'll get more into this shortly. So speaking of network interfaces, well, let's talk about them for a second. And so network interfaces are the points of connection between your computer and the network. And they can be physical interfaces, right? So you might have an Ethernet port or a Wi-Fi adapter or they can be virtual like a loop back interface or in the case of a VM, it's all technically virtualized. And each of these interfaces allows us to send or receive data over a network. And we can view all of the network interfaces on our system by running iplink show. In this case, note that we have a loop back interface with this hello here that is used for internal communication within our system itself. And we also have an interface here. In my case, it's P0S3 that we're using to connect to the internet. And yours might be named differently, but for now, let's just make note of them. And so when we're using TCP dump, we need to specify which interface we want to capture packets from. And this is the highest level of capture filtering that we have because the network interface determines the scope of the traffic that we'll be monitoring and collecting. And if we don't specify an interface, well, TCP dump will search through our systems interface list for the lowest numbered one that's configured up, and we'll choose that one for the capture. And so to list the available network interfaces for capture within TCP dump, well, we can just provide the TACD option with no value. And because we're not monitoring anything yet, well, we actually don't need to prepen the pseudo command at this time. So if I hit run here, well, we can see we have all these available interfaces to choose, right? So we have that ENTP031. We have any here which will capture traffic on all interfaces. We have our loop back address. And then we have some additional ones here that we don't need to worry about. And so in some cases, you might want to monitor multiple network interfaces at the same time. TCP dump does not support capturing from multiple interfaces in a single command directly. But you can run multiple instances of TCP dump each capturing from a different interface. And if we do that, well, we can use tools like Wireshark or Mergecap, which can merge multiple capture files into one file for analysis. And assuming your kernel supports it, in this case we of course do, well, we can run TCP dump with the any option for the interface, which will capture traffic on all interfaces. But if we do select the any option, well, we won't be able to capture traffic in promiscuous mode. And that's a type of network interface mode that allows a network device like our network interface card to intercept and read all network traffic that passes through it regardless of whether our traffic is addressed to that device or not. And again, that's why it's best practice to set an interface when we're configuring TCP dump. And so, we've listed our interfaces, but how do we actually specify one? Well, we can run TCP dump here and provide the TAC I flag or the I argument followed by the interface name or the index number, right? So, you can see these are numbered. This index one here refers to entpex 2 here refers to any. So, in the case that we want to monitor our loop back address, well, I can either type hello or I can provide the number three. In this case, I'll just type hello. And if I just hit enter, well, we're going to start monitoring the traffic on our local loop back interface. And so now that we're listening for network connections on our loop back interface, well, let's start simulating some traffic. And this will be very similar to what we did in the network security theory lesson where we looked at the individual TCP handshake packets. And so what I'm going to do is press control, shift, and t to open up another terminal. And I'm just going to zoom this in. And I'm going to open a third one by again pressing control shift and t. And if you recall what we did last time, well, I'm going to use the netcat utility, which is a utility that can read and write to network connections. And so I'm going to set up a listening server here. And I'm just going to run NC for netcat. I'm going to provide the L flag or the L argument here to listen. I'm going to provide the V argument to make it verbose. So we're actually going to see some output when we get a connection. And the TAC P flag to specify the port that we want to listen on. In this case, I will do 4 3 2 1 for the port. And again, if you recall from last time, we can actually combine these arguments together. And so I'll just remove the dashes there and just keep one set of dashes to provide - LVP to include all of those arguments. And so you can see we're listening on port 4321. I'm going to head over to our third tab here. And if we think of this one as the server, well, this third tab here is going to be our client. And so now I'm going to type the netcat utility again. And in this time, I'm not listening, but I'm connecting to our local host on 127.0.0.1. Remember, we could also type local host as well instead, but I'll just keep the IP address. I'm going to provide the TAC V flag once again to make it verbose. And then I just need to provide the port number 4321. And if I hit run here, well, you can see we have succeeded and made a connection to our local host on that port. If we head back over to our server, well, we can see the connection was received. And again, we have our highle port here or our ephemeral port that our operating system chose for the client's connection. If we head back over to TCP dump, well, you can see we caught the entire 3-way handshake. So, if we think of this as a single line, well, this is our sin based on the TCP flag with the capital S. This next line here is going to be the sin act. And lastly, this third line here is going to be the final act. And so this can kind of be a little difficult to read at first, especially on this screen when I have it zoomed in. So let's look at the first line once again and let's see if we can make out the different fields that are being logged in this connection. Right? So at first here we have what looks like a timestamp and this indicates the time at which the packet was captured and this is the default format of the timestamp and we'll get into this later but we can tell TCP dump to display this in a different format like Unix time if we'd like. Next here we have the protocol which we can see is the internet protocol or IP. And if you remember the concept of encapsulation well inside this protocol we would have the TCP header. This third field here we can see localhost 54388. So this specifies the source address and port. So if you recall localhost refers to that 127.0.0.1 and this is the source port number making the initial SIN connection. This arrow here indicates the direction of the packet from source to destination. And so obviously everything on the right of this arrow here is going to be the destination address and the destination port separated by this period. So next we have the flag section. And we've covered this quite a bit, right? So this indicates the TCP flags that were set on the packet. And of course in this case the capital S here stands for SIN which is used to initiate the TCP connection. Next we have our sequence number. And so this is the initial sequence number for the TCP connection which is that randomly chosen 32-bit number. Next here we have window size. If you remember when we broke down a TCP packet, well, we had a field for window size and this is the size of the TCP receive window which indicates the amount of data in bytes that the sender is willing to receive. We don't really need to worry about this at this stage. We also have a section here listing all of the TCP header options, which we don't really need to worry about. And lastly, we have the length of the actual payload data. In this case, we were just initiating a connection. So, we don't actually have a length specified here because this is a SIN packet. Well, it doesn't carry any payload data. So, hopefully that makes it a bit easier to start going through these TCP packets. And so, if I return to our client here and just send a hello message, well, we can see the specific packet of that message. We can see by the length of six here. So there was actual payload data within this packet. And you can see to send over the message, we had a push flag set and an acknowledgement flag set. And when the listening server received the message, well, they sent back an act. And so all of the data that we're sending back and forth here over netcat is unencrypted, meaning that it's in plain text format. So let's see if we can view this payload within our packet capture. And so let's cancel out our TCB dump instance by pressing Ctrl and C. And then let's start up a new one. So I'm just going to clear the screen and start it up again. This time let's add the capital X flag. And so this capital X argument here is going to tell TCP dump to print each packet in both hexadimal and ASKI format. And so essentially it's going to show the raw packets in hexadeimal allowing you to see the individual bytes of the data and then provides the corresponding ASKI characters making it easier to interpret the content of the packet. Right? Right. So, I'm just going to listen here and let's send another client hello message. And so, I'm going to head back over and this time we get a lot more information. We can actually see some of the payload data. So, this looks very similar. We have our length of six here from our hello message. We have the push and the act set, but we have all of this hexodimal data here. And if we look over to the ASI of that data, well, we can make out our hello message right here. So in this case, we can actually decode the unencrypted message that we sent over. And so I'm going to cancel this again. And instead of the X flag, this time I'm going to select the capital A. And this is another common flag or argument that you'll see. And the capital A argument tells TCP dump to just print out the ASKY data. And so in this case, we're not going to get any hex output, which is really useful when it comes to things like looking at HTTP requests or responses. It makes the output a lot cleaner for us. So to demonstrate this, let's start a listening HTTP server on port 80 on our local system. So I'm going to close out our server here with C and our client with control C. And in this case, I'm going to go back to our server tab and I'm going to run the pseudo python 3 tac m http.server 80. And this is going to start a listening HTTP server on port 80 on our local system. Right? So, you'll need your password here because it's going to be using port 80, which is a low-level port. And so, you can see here that we're serving HTTP on port 80. And so, I'm going to head back over to our client tab. And in this case, we can use the curl utility to make a get request on our listening HTTP server for a file that doesn't exist. So, in this case, I'm going to put in http/ localhost or remember 127.0.0.1. And I'm going to ask for the file. Well, this file doesn't exist.php. And so, let's run that. And you can see, as expected, we got an error code of 404 or the file was not found. If we return to our TCP dump tab, well, we get a lot more information here, right? Let me scroll up a bit and you can see we get the full ASKI output or the full payload of the received packets, allowing us to see the HTML response that we return from the web server. If we scroll up a bit more, we can also see the HTTP response headers. So, we can see headers like the server name, so simple HTTP. We can see the date of the connection or we can see things like the content length. If we scroll up even more to the original request, well, we can see the original get request to the server on this specified URL. We can even see things like the user agent. In this case, we were using curl. And so, these examples were fairly straightforward. And I just wanted to give a quick introduction to the TCB dump tool. And so our focus is now going to shift towards capturing and filtering network data, which is where the bulk of this tool's features and arguments come into play. And so with that, thank you for sticking along and I will see you in the next lesson. In the previous lesson, we looked at the basics of TCP dump and how we can select our interfaces and view captured payload data in a variety of formats. And a big part of capturing live traffic is the actual capture filters we put in place before we begin monitoring. And so it's important to understand that typically in network traffic analysis, we'll have both capture and display filter capabilities within our tooling. And so capture filters are the initial parameters that we establish before we begin monitoring. And these allow us to specify the type of traffic we want to capture, right? Like the specific protocols or the source and destination IP addresses or port numbers. On the other hand, display filters are applied after capturing the traffic and are used to selectively display or analyze specific packets within the captured data set. And so in the last lesson, we looked at our loop back interface. In this case, I'm going to run TCP dump again with the capital D option. And notice that in my case on my machine, this is the interface I have that's connected to the internet. And yours might be named differently. You might need to run an if config or an IP command to figure out which network interface you have up and running. I'm going to run pseudo TCP dump with the TAC I for the interface flag and specify ENTP03 as my interface. And if we just let this run with no filters on a real network, well, we would very quickly be flooded with traffic. And so if I open up a new tab here and if I just curl the TCM website, well, you can see all of the packets that were involved in that one connection. So, first you'll notice that TCP dump is converting or resolving IP addresses into host names. Well, this isn't so much of a capture filter as much as a display filter, but just to make our lives easier and is also good practice when we want to look at just IP addresses. Well, we can run this again, but use the N argument with all our commands to prevent TCP dump from converting addresses like the host addresses or the ports into names. So if I listen again and we make another curl request, well you can see this time instead of https what we got 443 for the port. Instead of the DNS name, what we're just getting the IP address here and so let's start now with actual filters or capture filters. And the first one we have here is called host. And so we don't need a dash in front of this. It's just host on its own. And as the name suggests, the host filter will only capture packets involving a specific host within the connection. Right? So if I put example.com here, and it can be a host name or an IP address. In this case, I'll just use example.com for the domain name. Well, let's start listening. And in this case, I'm going to open up Firefox and start opening some random websites. If I go to google.com, well, we get nothing. If I go to Wikipedia, we also get nothing. However, if I go to example.com, well, do you think we're going to log some TCB connections here? Well, in fact, we are. And so, you can see that we weren't capturing any traffic when we navigated to any other website or domain. But when we navigated to example.com, we should be able to see the original three-way handshake and any subsequent acts that were being made. And so, this filter can obviously become very useful when we want to monitor traffic from a known malicious domain or a suspicious site, right? because the host command is going to look at both the source or the destination. And so while the host filter can filter out traffic that involves a particular host or IP address regardless of whether the IP is the sender or receiver, well, we also have the source filter or the destination filter. So that's SRC for source or DST for destination. And these allow us to filter specific senders and recipients of traffic. Right? So the source here is going to capture packets originating from a specific source or IP address. And the destination on the other hand is going to capture packets that are destined for a specific host or IP address. Just for example, if I run the IP command and look up the address, well I can see that my IP address is 10.0.2.15. So if I run TCP dump again and this time I can specify a source of 10.0.2.15. And so this is only going to capture packets that originated from my own IP address. Right? So if I start listening and then just curlgoole.com, well, we can see we captured all of those packets. And now we can't really demonstrate what isn't being logged since we're just in a lab environment with one machine. But more interestingly, we can set a specific destination address, right? So if I run the dig command on google.com, well, I can see in my case, I'm getting this IP address resolved. So if I copy this IP address and run TCP dump again, this time I will specify a destination of that IP address. And now I can use the IP address here. But again I could just put google.com. But just to demonstrate more use cases here, I will put the IP address. And so if I curl Google.com again, well you can see we of course did capture those packets. And now along with individual hosts or IP addresses, we can also filter TCP dump to only capture traffic to and from a specific subnet or range using cider notation. And so we can do this with the net filter here. And this is going to capture traffic to and from a specific network, right? So I could put 10.0.0.0/8 to capture the entire subnet there. But we also have the ability to modify this to be the source net. Right? Okay, so this is going to capture packets originating from a specific network, right? Or I could modify this once more to destination net. And as suspected, this is going to capture packets that are destined for a specific destination network. And this could be useful in the case of a C2 server or a command and control server that might be talking to different IP addresses within the same network, right? So we can start to narrow down the traffic using the net filter. And so another common filter we have is port, right? And so port is going to capture packets based on specific port numbers. And so we could capture everything happening on a single port, right? I can put 3389 here if we want to just log RDP traffic or port 21 if we want to capture anything related to FTP. And we can further break this down once again with source port and destination port. And so you can see the syntax here is pretty consistent and easy to remember. And before we demonstrate some more specific filters like ports, well, we should first talk about the concept of logical operators within TCP dump. Right? So TCP dump provides logical operators using words like and or or not to combine multiple filter expressions into a more refined capture. Right? So being able to capture various things on their own is really powerful. But the real power of TCP dump comes from the ability to combine different options in order to isolate exactly what we're looking for. Right? So we can think about some examples where these logical operators might come in handy. So let's say we're looking for any RDP traffic that's originating from a specific system or IP address, right? So we could simply put in the source here for 10.0.2.10, but we could also include and here to look for the destination port of 3389. Alternatively, let's say we wanted to capture traffic on a remote device that we remoted into using SSH. Well, if we were to do that and fire off TCP dump, well, we're going to capture a lot of packets related to our own SSH session, which we might not want. And so, we could modify this to be something like and not port 22. And so, as we start building more complex queries, well, it's going to be best practice that we start wrapping our filters within quotes, right? And so this will allow us to use more complex operators like brackets without having to manually escape them and allows us to group various expressions and have them evaluate correctly. Right? So let's think of a complex scenario here. And I'm going to wrap everything in these single quotes. And so let's say we were looking for the source of 10.0.2.15 and the destination of 40.123.123.123. And we don't want the ports to be 443 or port 22. Right? So assuming I type that correctly, the brackets in the not expression as we can see here serve to group the logical operations together. Right? So this ensures that the logical negation applies to both ports 443 and 22. Without brackets, the not operator would only apply to the first port here. So altogether this command is going to capture network traffic on our interface here originating from this IP address and destined for this IP address while excluding traffic on ports 443 and port 22. Right? So we can demonstrate this. Let me just netcat that 40.123123123 address. And I'm going to specify port 443. Well, we're obviously not going to get a response back from the server. So I can cancel that. But you can see we log nothing over on TCP dump. So let me try that again. Maybe it was a fluke. Let me try port 22 or SSH again. We're not going to be able to connect here. But we should still see the packets being logged. And again, nothing. So what if we try a port that we didn't specify, right? Let's try 1 2 3 4. And if we hop back over, well, we can see some sin flags that were sent over. So in this case, our filter was pretty specific. Cool. And so finally, TCP dump allows us to filter packets based on their protocol, right? So to filter packets based on protocol, well, let me just get rid of all this mess, we can simply use the protocol's name as the filter expression, right? So some common ones you might see obviously TCP if we just want to look at TCP packets or of course UDP. We can look at ICMP. Remember that's a completely different protocol. So if we just want to see those echo requests and replies well we can specify ICMP here or we can supply ARP right the address resolution protocol which is used for mapping IP addresses to MAC addresses on local networks. So these are the most common ones you'll see and of course we could even exclude any of these protocols using the not operator. And so obviously we don't have time to cover every single combination of useful capture filters out there. But I will add that the man page or the manual page for TCP dump is very well written and can give you an entire deep dive on any useful flag and argument out there. Right. So to view the man page, well, we can simply use the man command, give it the name TCP dump, and we can pipe this to the less command so we can see an easier output, right? So we can get the usage information. We can get a description of the utility. We can get all of the different options that we have available to us. And we're going to cover some more of these shortly. And if we scroll down to examples, well, we can see all of these very useful examples or use cases of TCP dump. Right? So if we wanted to get as deep as to print the TCP packets with the reset and acknowledgement flag both set, well, we can use something like this, right? If we wanted to print the IP packets longer than 576 bytes and sent through a specific gateway, well, we can use this command. And obviously, we can change any of these parameters here. This is just a sort of list here to get you started. And so to quit this, by the way, you can just press Q. And so again, I'll stress that the most important skill to pick up here is the ability to combine various options and logical operators in order to isolate exactly what you're looking for in a given scenario. And so this is going to require a lot of logical thinking and a lot of trial and error and also a lot of practice. And so, like I did with the fishing analysis section of this course, well, at the end of this section, I'll compile some useful resources for you to get your hands on and also do additional practice on dissecting and analyzing real pcaps. But before we can obtain pcaps, well, we need to learn how to save them to a file. And then in the next lesson, we're going to actually analyze them. And so, thankfully, TCP dump makes this incredibly simple to do. And so the ability to save and write the network traffic that we capture into a file is obviously very useful when it comes to future analysis. Right? So it gives us the ability to do things like offline analysis or process pcaps in other tools like wireark or an IDS system or even back into TCB dump itself which we're going to do in the next lesson. And so to save any of our output into a pcap file, we just need to provide the W option here followed by the name of the file where we want to save the capture. So in this case, I'm going to send it over to the desktop under the network security TCP dump folder. And then I'm going to call it capture.pcap. And in this case, it doesn't really matter what filters you're using or anything or what interface. We're just going to practice saving a file. And so I'm going to run this now. And then I'm just going to ping google.com. And if we hop back over, well, we can see nothing was captured in standard output. But if I cancel this now, we can see that 10 packets were received by the filter and they were saved into this capture.pcap file. Right? So if I run the file command and specify the location, well, we can see that it's a pcap capture file. And we can even see the length here indicating that we did in fact save those packets. And if we want to verify this further, well, we're skipping ahead a bit here. But in this case, instead of the W flag to write, well, I'm going to change this to an R to read from this file. And if I just hit run, well, we can see all of those ICMP echo requests. And so we can apply any of the filters we just covered onto this pre-existing data or this pre-existing packet capture, right? So if I just specify the protocol of ICMP, well, we should still get everything returned, right? But if I change this to TCP, well, we get nothing. And so I think this was a good adventure into the various live capture filters that we have available to us within TCP dump. And as I mentioned, in the next lesson, we're going to look at some real pcap files and start building up a very strong strategy and methodology and different commands that we can use to parse and make sense of network traffic in the command line. And so I look forward to seeing you in the next lesson. Okay, now that we know how to capture and filter traffic with DCB dump, it's time to do some practical command line network traffic analysis using real pcap files from infected machines that were involved in malware campaigns in the wild. And so if you recall in the last lesson, we saved a packet capture into a capture.pcap file. And if I just ls my directory here, well, we can see that capture.pcap file. We can simply view this packet capture within TCP dump by using the -ash r argument to read in the pcap. So if I just run tcp dump with r and then I'm just going to provide capture.pcap. And you can see just like in the end of the last lesson, well we can read in this file that just contained ICMP echo requests and replies. Before we dive into the real examples, there are a few more display commands that will come in handy as we investigate packet captures. The first one is the count. So if I just clear this and run it again, I'm going to provide two dashes here and then the word count. And the count option is used to display the number or the count of packets that are currently matched by our filter expressions. So if we don't provide any filters, well, we're going to get the total amount of packets within our entire pcap. And so you can see here we have 10 total packets. And so this is obviously useful in quickly determining how many packets match a certain criteria without needing to display all of the packet details. The next option here is just -ash c. And this option specifies the total number of packets that we want to capture when we're writing to a file or the number of packets that we want to return when we're reading from a file. And so this is useful if you only need to see or save a subset of packets in a larger pcap file. For example, to only return the first two packets in this pcap, well, I can provide the number two here. And you can see we're just getting those two lines. Lastly, here we have some commands related to timestamps. So, you can see the very first field we have here is the timestamp. And that is in our local relative time. We have a few options depending on how many t's we provide in the t argument. So what I mean by that is if we just provide one t in this dash t well we're going to completely remove the time stamp altogether from printing. So it basically suppresses any time stamp. However, if I put two t's this is going to convert the time stamp into the standard Unix epoch time. And this can be very useful in documentation purposes because it's sometimes better to have a UTC time stamp versus a relative one. Well, we also have the tac ttt or the 3T's which is going to print the timestamp in milliseconds since the previous packet. So essentially if we run this, we're only going to get the deltas between each packet. Right? And lastly here the four T's is going to print the time stamp in the standard date and time format. So that year, month, date, hours, minutes, seconds. And so we can see how this is also a useful modifier if we want to display the timestamp in an easyto- read format. And so with that, let's jump into our first pcap example. So head over to the pcaps folder within the TCP dump directory. And let's start with the 2021-09-14.pcap file. And this contains a capture of a host infected with lockbit, a popular and known info stealer and remote access trojan piece of malware. And so how should we first approach this? Well, there are many different ways and methodologies, but I like to obviously start from a wide 50,000 foot view and then narrow down the search once I've identified any interesting conversations or IP addresses. And then I'll do some more detailed analysis. And with any various IoC's or suspicious IP addresses I find, I might need to zoom back out and look at the bigger picture again to determine the scope. And so I'll also say that we'll be slightly limited in the amount of detailed analysis that we can perform just through the command line. And so while I say TCB dump is a fantastic tool for capturing packets and it offers many speed and scalability advantages over something like Wireshark, well Wireshark is arguably better at performing individual packet analysis due to its statistical and advanced filter features, but we will get to Wireshark in due time. And they're both very important tools to grasp. So let's start out with the most simple command to just read the file and see what we're dealing with. So, if you recall, I'm just going to run TCP dump, provide the R flag here, and then just provide the name of the file. In this case, that 2021-09-14.pcap file. And we're getting a lot of packets. So, what we can do, if you remember, we have the count command, so we can identify how many packets we're dealing with. In this case, we have around 3,600 packets. And as good practice, like I said, I'm going to display the timestamps in Unix epoch time. And so to do that, I'm just going to prepend the -ashtt there in front of all of our commands just so we can get the timestamps in that format. And so let's start by going through some of this at a very high level. And in this case, I don't want to provide the N argument yet because I might be interested in some of the domain names that we identify. And as I scroll up here, I'm seeing quite a bit of traffic between this 10.0.0.168 address and this 103.23255.14 232.55.148 address. And this also appears to be port 80 or HTTP traffic, which is going to be useful for us since it's unencrypted. And so for my first filter, I'm just going to specify that we only want to look at port 80 traffic as either the source or destination port. And so to do that, I can just provide the port argument and just put 80. In this case, I'll narrow down the count here so we can see how many we've cut down. In this case, about over a thousand packets, which is nice. And again, I was noticing some conversations between those two IPs that I identified. And during real traffic analysis, we'd probably know the affected endpoint source IP address, likely from the ticket or the incident details. However, in this case, I can make the assumption since it's the only internal IP I've seen so far, that this is probably the source IP of the endpoint. In which case, I'll add this IP to our filter as the host. And I'll just modify our command a bit to include and with the host of 10.0.068. And since we're dealing with HTTP, I also want to search for any get or post requests, which we can actually do by leveraging the ever useful GP command. And so we can pipe our output here into GP. And we can then search for any instances with get or post that show up in the HTTP headers. And a get request in HTTP would be like a web request to retrieve information like fetch me this web page. And a post request on the other hand would be a request to a web page where we're sending in data in what we would call post parameters within the HTTP body. And this could be things like credentials or information in a form and many other possibilities. And so it can be quite useful to narrow down web requests like these especially when the connection is unencrypted. And so to specify our parameters within GP here, I'm going to give it the capital E option. So we can specify an expression. And in this case, I'm going to wrap it in double quotes. And I apologize as it's gone to a second line, but I'm just going to provide and then pipe that to post, meaning that we're going to match any words that are get or post. And so if I run this, so we can see a number of different URLs or endpoints that we could perhaps cross reference with our web proxy or firewall logs if we had them. However, there's one URL or path listed here that makes me very curious and suspicious. And can you see it? Well, it's this one right here, which is very interesting. And it suggests that the endpoint downloaded an executable file called audiodg.exe. And any.exe extension should get our ears perking up. And the dot in front of the file name here is also quite suspicious, right? So in file systems, a dot at the beginning of a file name often signifies a hidden file. However, this is more common in Unix like operating systems and is not something we typically see in Windows environments. So this might be an unusual naming convention or an attempt to mask a malicious file with a false extension. And so I'm just going to copy the name of this executable here. And if we perform some very basic OSINT by Google searching the name of the file in quotes. Well, we can see that it might relate to the Windows audio device graph. However, the curious thing here is that in our pcap, this file doesn't seem to have been downloaded through an official Microsoft channel. And the dot at the beginning of the file name is now even more suspicious. And so let's return to our original methodology that we built through the fishing analysis section of this course. And so we've identified a suspicious file name here that came from an identified indicator of compromise or IOC. In this case, we have the IP address of 103.232.55.148. And I'd say a good call here is to do a lookup of this IP address to confirm whether or not this really is affiliated with Microsoft in any way. And so I'll just head over to the domain tools website and paste in this IP. And we can see that it's affiliated with a server technology company located in Vietnam. And it's in no way related to Microsoft. So we've identified two IoC's hinting at a malware infection in the form of a file name and an IP address. And so let's step back in our filters and perform a more generic search using GP for any packet that contains the audiodg.exe file. And so I'll just clear this out and I'm going to remove all of these filters and just search for audiodg.exe. And it shouldn't matter that we don't have the dot at the beginning. And so it looks like we have two results. The first one here seems to be including a URL within the query parameters of this API. And the URL within these parameters, well points to the same IP address that we just identified. And so let's start opening these packets up to the best of our limited ability within TCP dump. And so I'll modify our command a bit here. And so because I want to open the ASKI output of the payloads contained within these packets, well I will apply the capital A argument to TCP dump. Additionally, I'm going to modify our GP command slightly to also append a capital A. Now this is a different one. With GP, we can append the capital A to retrieve a number of trailing lines after we match our GP results. And so, because we're opening up the payloads that are going to be multi-lined, well, we can tell GP that we want to also display the trailing 500 lines or so after we match the audiodg.exe string. So, this is not the cleanest way to do this, but we are limited to command line tools here. And so, before I run this, I'm going to pipe it once again to the less command. And this will make the output a lot easier for us to scroll through. And so immediately we can see this first result here. So we're opening up that first packet that was pointing to this endpoint here, this API. And if we look in the HTTP host header, well, we can see it's pointing to api.bing.com. And we can also see the destination address here is 13.107.5.80. And if we do a lookup of this IP address, well, we can see that it is in fact associated with Microsoft and likely Bing. And so based on this oddlook URL, it seems to be designed to interact with Bing search's API to either query information or abuse it in some way to redirect to the provided URL, which we discovered is hosting that executable file. And so I'm going to copy the entire URL within this query parameter and head over to Cybershere to see if we can decode the URL. And so I'm just going to search for the URL decode and drag it over to the recipe. And we can see the full URL. And while we're here, we should probably defang it as well as it's good practice for our documentation. And now this definitely looks like a potentially malicious URL to me. Partly due to the IP address instead of a domain name. the HTTP protocol and also the fact that it's serving an executable file. And so I'm just going to copy this URL quickly and head over to virus total. And I did mention earlier we would be using a lot of these tools all throughout our different investigations. And if I go under the URL section and paste in that URL, well, we can see that it was flagged by six vendors as malicious, which supports our investigation. And if we head back over to our output here and scroll to the second packet, well, we can see the beginning packets that contain the actual download of the executable file. And specifically, we will find this string here of this program cannot be run in DOSS mode. And this is a string that's often found at the beginning of a Windows executable file and is part of the DOSS header. And so, we've successfully found the main malicious IOC within this pcap file, all through using TCB dump filters and GP. If we wanted to take this any further and actually extract the executable file or obtain its hashes for further analysis, well, we would typically have to use something like Wireark to do that. And so, I hope this example wasn't too complex. But you can see how it can sort of get a little difficult to do things solely from the command line, which is why we have other tools and options available to us. But it is still important to know how to do some of this stuff, like using GP and doing different filtering options to find what we're looking for. And so since this video got a bit longer than I thought, I'm going to save the second analysis for the next video. So I will see you in the next video. All right, so let's go through another example. And this time, we'll get to chain some more useful command line utilities together to parse through some more packets. And in this scenario, we have a packet capture from a Cobalt Strike Beacon after a user fell victim to a malicious macro enabled Word document. And in this case, we're going to be looking at the 2024-04-18.pcap pcap file. And so let's start off by seeing how many packets we have to deal with. So I'm going to read in that file and then I'm going to provide the d- count argument. You can see we have almost 10,000 packets here. So a bit more than the last time. And so let's start out by doing something that is incredibly easy to do in something like Wireshark, but is a little more complicated when viewing a packet capture in TCP dump. And that involves looking at statistics of conversations and IPs and ports. And so first, let's look at the top source IP addresses. And so to do that, I'm going to run TCP dump. I'm going to provide two T's here to convert the timestamp into Unix time. I'm going to read in the file. Once again, since I'm just dealing with IPs right now, I'm going to provide the N argument so we don't resolve any IP addresses to names. And the only filter I'm going to use right now is TCP. This is because at this point I'm not concerned with any ICMP or ARP or any UDP packets. And I'm just going to run this so we can see what the output looks like. Okay, excellent. I'm going to give us a bit of space here. And I'm going to rerun the command again. This time I'm going to pipe it to a very useful command called cut. And we're going to cover cut in a lot more detail during the log analysis and sim section because it's really one of those Swiss Army knife tools that every sock analyst should master because it really helps you parse through logs very quickly. And in this case, the cut command allows us to specify a delimiter with the tac d option. And in this case, I'm going to put the delimiter in quotes. And for the delimiter itself, I'm just going to press the space bar to add in a space. Because if you look at some of these outputs here, we have a field and then we have a delimiter of a space and then we have another field for the protocol and then another space and then the IP address. And so this is the field that I want to extract. And so in this case, I can provide the -f option to specify the field that we're cutting. And in this case, if we count, we have one field, two fields, and three fields. And so I'll just provide the number three. And if I run this, well, you can see we're just cutting the IP addresses. However, due to the way that TCP dump organizes things, we're also getting the port numbers appended at the end. So in this case, we can pipe this to yet another cut command. And in this case, we can specify the delimiter of the period. And if we think about the periods in these outputs, well, we have one field, two fields, three fields, four and five. So in this case, we want to grab fields one to four, but exclude five. And so for the fields option, I can just provide 1 to four. So we can provide that range there with the dash. And so I'll run this one more time. And you can see we're just getting the IP addresses now. And so this is great, but we have a lot of IP addresses here. We're not doing any kind of filtering or sorting. And so that's where the sort command comes in, which is another very useful command that again we're going to cover in some more detail later on. But let this be a introduction to it if you haven't used it already. And so I'm going to pipe this output once again into the sort command. And let's see how that changes things. Well, we can see that all the IP addresses have been sorted in descending order. And so that's useful, but how do we cut down on the duplicate entries? Well, that is where we can pipe this into the unique command. And that's going to cut down all of the entries that are duplicates on the same line. Right? So you can see we had a bunch of 85s here. This IP address duplicated on the same line. And so unique is going to cut down on all of these. So it aggregates into a single line. And a modifier that we can add to the unique command is the C option or the C argument which will display a nice count for us. And so this is the amount of unique aggregated entries of that single IP address. And so this is great. We're almost there. However, we can do one more sort command here with the -ash nr with the n being a numeric sort to compare the string against the numerical data of the count values here. NR to do it in reverse. And so if we run this, we will finally get a nice and sorted list with all of the source IP addresses within this pcap file. And if we scroll up, well, we can see that the top IP address here is this 10.4.18.169. And in second place, we have this 85.23. 239.53.219. We also have some other interesting IPs as well. And so similarly we can run the same command but we just need to change the first value here from sorting on the third field to the fifth. And in this case we will get the top destination IP addresses. Right? So if I run that and we scroll back to the top well we're getting the same results basically because the source and destination seem to be talking to each other the most. And so we again we have this 10.4 4 and this 85.239. And so from these initial statistics, it looks like this private IP address might be the affected endpoint. And this one right here is a potentially interesting IP to look into. And so I'm going to get rid of all these cut commands here. And I'm going to specify that we want the source of 10.418.169 and the destination IP of 85.23953.29. And if we just run a count on these, well, we can see that we've narrowed this down to about a thousand packets, which is nice. And so now let's aggregate and get some statistics on the top ports that these two IP addresses are using in their communications. And so to do this, let me just clear this all out. I'm going to remove the count here. And I'm going to pipe the output of, you know, these filters here with the source and destination. And I'm going to cut based on the space again. And this time I want the third field again because remember we're getting the IP and the port. And so we want to pipe this to another cut command for any periods. And in this case we only want the fifth field. And that's just going to return the ports. And so now it's just a matter of sorting and grabbing the unique and then sorting once more. And you can see we're now getting the top source port numbers. And if we just modify this slightly and in this case I'm just going to change source here to destination and then I'll change destination to source to basically reverse this filter. And you can see we're only returning port 80 as the destination port. And so we can see that the majority of traffic is on port 80 or HTTP and what looks like a number of ephemeral or highle ports from the client's end which of course makes sense. And so now that we know that we're just dealing with port 80 traffic, well, let's look a bit deeper. And if you recall what we did with our previous pcap, well, we can pull back things like the HTTP get or post headers from the packets themselves using GP. And so I'll just search on that source and destination IP. And then I'll type this to GP where we'll provide the capital E to do an expression. And then we want to look for get or post. If we run this, well, we can see a number of post requests to this API endpoint. And this endpoint has a seemingly unique identifier here, which is very curious. And so, let's try opening up some of these packets. And so, I'm going to clear this out. And this time, I'm going to provide the - C argument to TCP dump to only pull back the first five packets here. And in this case, I'm going to provide the capital A argument to open up the packet in that ASI format. And so when we do that, well, we get a very interesting content type here of Los Angeles and a user agent of SS load 1.1. And I've never seen this user agent string before. And so I'm going to copy SS load and once again do some more OSINT and just Google to see if I can find any information. And when I search for SS load, well, I can immediately see this Malpedia article here specifying that it's part of a malware family. And we can see that SSL load is a rustbased downloader that is used to deliver secondary payloads. And we can see that the first stage of the malware connects to a telegram channel named SS load to retrieve another URL. We can see that it downloads a compressed PE file or an executable file using a hard-coded user agent of SS load 1.x. And this is the user agent that we saw in our HTTP headers. If I go back to Google here and search SS load, well, I can see this GitHub URL. And in this case, we can see a number of additional IOC's that we can perhaps look out for in our pcap file. For example, this appears to be the Telegram link because I know from experience that t.m me is a domain owned and operated by Telegram. We can see this IP address which we actually already discovered. So, this is that 85.239 IP address. We can see that it downloads an encrypted payload on this URL. So let's see if we can find the domain name associated with that IP address. And so in this case, I'm just going to provide the filter of host. And I'm going to provide that 85.23953.29. And if I run this, well, we can see a very interesting domain name here. And it appears based on this first subdomain, it's using some sort of dynamic DNS to have a random value for this subdomain. And so with that, I will take the base domain here of first opportunity.online and head back to Virus Total to see if I can find any information about this domain name. If I search under the URL tab for that domain name, well, we can see that two security vendors here flagged the URL or the domain as malicious. And so since we were seeing a large number of post requests, well, let's try opening up some of the packets to see if any passwords or credentials were submitted. And we can actually do that through some clever expressions within Grep. And so I'll run the command again. In this case, I'll append the capital A so we can see the ASKY output of the payload. And I'll pipe this over to Grep where I'll use -ash I to make sure it's case insensitive. Within our search here, I will look for any results that contain the word user or pass for password or login. And if we run this, well, we're actually getting all of the user agent strings, which isn't very useful. So, what I can do is pipe this to yet another GP command. And this time, I'll use -ashv to exclude the word user agent. Now, if I run this, we should get any other outputs. And in this case, we get a very interesting object here. So we can actually see some key value pairs that might relate to the beacon or information related to the affected endpoint that was being sent over to the attacker. So we can see things like an IP address here. We can see the domain that the affected endpoint was likely on. We can see the host name of the affected system. We can see the architecture and operating system version. We can even see the user that was logged in. And we're getting all this information just from the keep alive object inside this packet. And so let's also use GP to see if we can find any files that were downloaded. And so sometimes HTTP packets will contain a file name header to specify the name of a file being downloaded. And in this case, I'm just going to search for the string of file name. And if we run this, well, we can see some interesting results. We are seeing this crypted_dll.bin file. And so this is definitely something we want to open up in Wireshark now to get more details on the payload that was downloaded. But we will save this for another lesson. And so while we're here, let's see if we can hunt down the remaining IoC's. And so if you recall, we actually had reference to a TM me domain here, which actually relates to the Telegram messaging service, which is sometimes used as a C2 or command and control channel for attackers. And so let's do a search across our entire pcap file for anything related to T.M. me. And so I will search the entire file and just g for TM me. Interesting. So we can see some related DNS queries to that domain. And so in this case we have certain values like this which is the identifier for the DNS query. And this is a randomly generated number. In this case we have a with a question mark here. This indicates the type of DNS query that is being performed. In this case it's an A query which is used to translate a domain name to an IPv4 address. And lastly we have t.m me which is the actual domain name being queried. And so to put this all together, these packets represent DNS queries from our source endpoint asking for the IPv4 address correspondent to the domain name t.m me. And so if we change our filter here to search for the host of t.m me. Well, it looks like all of the traffic is HTTPS traffic on port 443, meaning that we can't really dig into the payloads without having the TLS certificate, which we typically don't have. And so lastly, the IoC's we found also mentioned a malicious DLL file that is used for the second stage of the malware. And so let's see if we perform a basic search here if we can pull back anything related to a DLL. And in this case, we actually did. We can see that the endpoint here made a get request for this 8080.dll file. And if I attempt to open this packet up with the capital A and then also append capital A with GP so I can pull back 50 lines and then pipe it over to less. Well, we can start to see the contents of the crypted_dll.bin file. But at this point, we really need to open this up in Wireshark as we can't do detailed analysis like this with TCP dump alone. And so these were two somewhat elaborate command line investigations to cap off our TCP dump lessons, but hopefully they showed you a bit of the general process and methodology on how we can use various display filters to zoom in and isolate what we're looking for and how we can use various IoC's we find to enhance our search. And so to conclude, TCP dump is a fantastic tool for quickly and efficiently capturing network traffic and aggregating network packets. However, in the next lessons that follow, we're going to take a look at Wireshark, which is a graphical packet analyzer, which will give us a lot more power in various features like statistics aggregation or conversation following that can make our investigations much easier. And so, at the end of the day, it's important that we cover and know both as you never know what you'll have access to in the field with certain incidents or scenarios. And so, with that, I will see you in the next lesson for the challenge and then see you over in the Wireshark section. Welcome to the Wireshark section of this course. As I've mentioned a few times already, Wireshark is another essential tool for anyone involved in either network troubleshooting and in our case, network traffic analysis. And as sock analysts, we need to know how to use it to both create and carve through and analyze pcaps when responding to malicious activity over the network. So there might be scenarios where we're handed a pcap file that contains suspicious traffic and we need to analyze it to identify various indicators of compromise or live incident response scenarios where we might need to actually remote in and capture packets directly from a compromised server or workstation. And so Wireshark is a free and open- source GUI based utility. So a graphical user interfacebased utility and is the most widely used network protocol analyzer in the world. And like with TCP dump, we can use Wireshark to do live capture and offline analysis of network traffic. So we can capture live network traffic through any of our network interfaces or analyze previously captured packets through pcap or other file formats. And because Wireshark is a graphic based tool, it offers several analysis advantages over TCP dump. And it allows us to do more of a deep inspection of various networking protocols and use things like powerful display filters to narrow down interesting traffic and even follow stateful conversations like TCP and HTTP data streams. And we can look at highle statistics which really helps the initial analysis process. And so when it comes to network packet analysis, many folks like to put Wireshark and TCP dump headto-head and have strong opinions on which is the better tool. And well, the truth is, like I said before, both Wireshark and TCP dump have their own strengths and weaknesses and are suitable for different purposes rather than one being categorically better than one another. And so TCP dump being a command linebased tool is known for its speed and efficiency. And it's especially useful in environments with high network throughput and data rates and large volumes of traffic. And like we said before, TCP dump is available on almost every Unixbased system, making it a powerful and ubiquitous tool and also doesn't require a graphical user interface. So it's ideal for headless servers and remote sessions. Wireshark on the other hand is really good at detailed packet analysis, right? So it makes navigating and filtering and analyzing network traffic much easier and it offers way more visualizations and statistics. But of course the drawbacks are it can be very resource inensive and often struggles with very high data rates and large capture files. And so if you have a very large pcap file, well, you might need to first carve it down with relevant filters with TCP dump or something like T-shark first and then load it into Wireshark once it's a lot smaller. And so in general, for real-time traffic capture on high-speed networks, TCP dump is more suitable due to its efficiency and scalability. But for in-depth analysis and visualization, Wireshark is the better choice. And so unlike TCP dump, Wireshark typically does not come bundled in to most default Linux distributions or with Windows. So, let's quickly cover the installation process for each. And so, on Linux, the easiest way uh is typically through your built-in package manager. And in our case, we're running Ubuntu. So, we really just need to run pseudoapp install Wireshark and say yes to the prompt there. And so, we will be met with this screen here when we're installing Wireshark. And this is basically asking us if non-root users should be able to capture packets. And if you remember with TCP dump, well, we couldn't actually start a capture without prepending it with pseudo because we need to be a root user or a super user in order to capture packets and interact with the network interface at that level. And so I'm just going to go with the default option here and say no. Excellent. So we have it installed now. And you'll notice if I just run Wireshark and don't worry about the interface yet. We'll get to this in due time. But if I just start a capture, well, you can see I'm getting this error. And this is because I did not start Wireark as pseudo. And so just remember if you select that default option there to prevent non-super users from capturing packets, well, you're going to run into this issue unless you start Wireshark as a super user or someone in the Wireshark group. And so to fix this this time I'm just going to run pseudo wireark and I should be able to capture packets with no problem. Now there is a way to get the latest and greatest release of wireark. And to do that we would need to run a couple of extra commands. And so I'll list the commands below if you want to install the latest release yourself. But just know we won't need it for this section. And so to do it, we would need to add the Wireshark dev repository to our package manager. And after doing so, we would just need to run a pseudo apt update and then pseudoapp install wireark. To download Wireshark on Windows, we can go to wireshark.org and click on get started. From here, you can select the installer applicable to your systems architecture. In this case, I will choose the Windows 64-bit installer. And once the download is complete, we can run the installer. And we can now go through this wizard to guide us through the installation process. Accept the license agreement. And here we can choose various components that we want to include or install with Wireshark. In this case, you can see T-Shark is already selected. And T-shark is a command line interface version of Wireshark and is more powerful than TCP dump or wind dump. We won't get into covering it in this section, but we can keep the defaults here and just click on next. Choose where you want to save the program. And if you don't already have it installed, it's going to install NPC for you as well. This is required in order for Wireshark to run. Once this is finished, we can click next and then finish. And now we can just search for Wireshark and run the application. And I'm going to hop back over to Linux now. But basically everything we cover here is going to be applicable to both the Windows and Linux version of Wireshark. So let's open up Wireshark and take a quick tour. And I'll mention that there are several options for us to start Wireshark directly from the command line. And there are several options that we can provide as we do that like specifying capture interfaces or opening up specific pcap files. For example, if I run pseudo wireshark with the -ash i here and select the03 interface with the k argument. Well, this will directly start a capture on that emp3 interface. However, I will just run pseudo Wireshark to open up the welcome screen. And so when you open Wireshark without starting a capture or opening a capture file, well, it will display this welcome screen which lists any recent open captured files if we had any. In this case, we don't. And also the available capture interfaces for capturing network traffic. And so just at a high level in terms of our user interface, you can see we have the menu bar at the top here. And this obviously contains various menus for file operations, right? So, we can open PECAP files. It's currently grayed out, but we could save captures as we start capturing packets. And we're going to return to a lot of these options here as we start capturing packets. We also have the main toolbar here, which is going to provide us quick access to common actions, right? So, like starting packet captures or stopping them. We could restart our packet capture. We can even open files this way as well. We also have a section here for capture filters, which we're going to get into in more detail in a future lesson. But the main area here is our list of interfaces. And you'll notice this is pretty similar to when we ran TCP dump with the capital D argument to list our interfaces. You'll also notice this little spark line here or this graph indicating if a current interface has packets going through it. And so this can be helpful if you're trying to figure out which interface you actually want to capture packets from. Right? If I just open Firefox and go to google.com, well, we're going to start to see a lot of traffic coming from our various interfaces as we interact with the internet. And so we can select any of these interfaces to capture from and we can also select multiple. Right? So we have the any option here to capture from all interfaces or we can click and hold control and select various other interfaces to collect both at the same time. Or I can hold shift and select everything. And if we hover over any of these interfaces, for example, this one here, well, we can see its IP address and any capture filters that are applied. So for example, let's start monitoring on our local loop back interface. So in this case, I'm going to select the loop back interface here. And let's recreate the same scenario that we've done a couple times already with netcat. And in doing so, we can get some simple and easy to read packets to start to dissect and understand the layout and feature set of wire. And once we go through this activity, well, we'll start loading in some real pcaps containing malware like we did with TCP dump. And so in this tab here, I'm just going to start up netcat and listen on port 1 2 3 4. And I'm going to return to Wireshark and double click the loop back interface here to immediately start our capture. So now that we're capturing packets, I'm going to open up another tab here with control shift and t. And then I'm going to connect with netcat on my local host on port 1 2 3 4. and we should see the three-way handshake taking place. And at this point, I'm going to stop the capture. And I'll just zoom in a little bit here. We're now looking at what is referred to as the main window. And Wireshark further breaks down this main window into three distinct sections. So, I'm going to click on a packet here. And you can kind of only see two here. This is because of my screen size. So, if this is happening to you, just go over to the right here. And you should see this little window here or this pane that got cut off. So we can drag this into view so we can see it more clearly. And so in the top here we're going to see this packet list pane. And this essentially provides a summary of each packet. So we can see we have different columns here like the source and destination IP addresses, the protocol, the length, even a timestamp. And so once we click on or select any of these packets, well, we can see the details in the other panes here are going to update. And I'm just going to drag this more into view. And so by default, we're going to see this list of columns here. So we have number here and this actually refers to the number of the packet within the capture file and this number is not going to change even if we use any of our display filters. This is something that Wireark adds to make navigating through packets easier. Next we have time here and so this refers to a timestamp of the packet and we can actually change the presentation format of the time stamp which we'll get into shortly. Under source here we obviously have the source address of where the packet is coming from and of course destination is where the packet is going to. We have the protocol here which is the abbreviation of whatever protocol is being used in this case transmission control protocol. We have the length of each packet as well as the info column here which shows additional information about the packet content itself. In this case we can see various things like the flags and the window size and sequence numbers very similar to what we were looking at in TCP dump. And so I mentioned this timestamp presentation. Well we can change the format here and the precision using this view menu at the top. And so if we click on view and then go to time display format. Well, by default, Wireshark is going to display the packets in seconds since the first captured packet. The most common format and typically best practice is to use the UTC date and time of day or we can also use the Unix timestamp with seconds since 19701. In this case, I will switch it to UTC date and time of day. And so next, you can see we have the packet details pane over here on the bottom left. And this will contain a detailed protocol breakdown of the packet that we select. And any lines you see with this arrow to the left, well, we can click on them to expand and find out more information. In this case, under transmission control protocol, well, we can open up the conversation completeness to see the flags that were set. And on the right here, we have the packet bytes pane because what we're seeing here is the hex output as well as the decoded asy content of the packet itself. And as we click on different areas in the packet details pane, well, it's going to highlight the related sections within the packet bytes pane as well. And so we can start going through some of these layers, right? So we have the frame here, and this will show us what frame we're looking at and details specific to the physical layer of the OSI model. Next, you can see we have the source and destination MAC addresses from the data link layer. Additionally, we have internet protocol version 4 here, which of course relates to the network layer and we can identify the source and destination address. So again, this is the entire IP packet that we're looking at. And lastly, of course, in this case, we have the transmission control protocol. And as we start looking at some more packets, well, we're going to see some more application protocols and application data within this packet details pane. We can see at the top here, we have the option to apply a display filter. So, this is the filter toolbar, and it allows us to quickly edit and apply display filters. We're going to cover display filters in much more detail in the next lesson. And at the very bottom here, we can see we have the name of the pcap file that we have open. In this case, it's set to a temporary value because we haven't actually saved this packet capture yet. But this status bar here can be very useful for us. For example, if I start hovering over different sections in the packet bytes pane here, well, we can see that the status bar here is going to update to the relevant column names that we can then filter off of once we start looking at display filters. Another very useful option available in Wireshark is packet colorization. And so we can set up Wireark so that it will colorize different packets according to a specific display filter that we set. And so we could potentially use this to emphasize various packets that we're interested in. And so there are two types of coloring rules in Wireshark. We have temporary rules that are only in effect until we quit the program. And we also have permanent rules that are saved in a preference file that are always available and will always be applied to whatever pcap we're looking at. And so temporary rules can be added by selecting a particular packet. And once we have a packet selected, we can press the control key along with one of the number keys to start automatically applying different colors to the conversation. And so to permanently colorize packets, we can click on the view option here and go down to coloring rules. If we click on this, well, we can see a number of the default coloring rules that Wireshark ships with. For example, if we have a TCP reset packet, well, it's going to be colored with this red background and yellow text. If we click on the green plus icon here, well, we can create our own coloring rule according to a specific display filter. And we don't have to worry about this yet. But let's see one of these default rules in action. And so I'm just going to start a new capture. And in this case, I'm simply going to curl localhost and fetch just a random file. And if we look back here, well, we can see some more colors. In this case, the port 80 traffic or the HTTP was in green. In this case, because we had a reset packet, well, that was in that red background with yellow text. And so I think this was a good start to installing and introducing the general UI of Wireshark. If it seems overwhelming now, don't worry too much because we're going to get into some more practical analysis and everything's going to start making sense once we start actually looking at pcap files. And so in the next video, we're going to look at how we can use the power of both capture and display filters to focus on and narrow down specific network traffic. And then we'll start analyzing some real pcaps. All right, welcome back to Wireshark. And Wireshark allows us to specify or limit the packet capture only to packets that match a particular capture filter. And Wireshark capture filters are written in the lib pcap filter language. And lucky for us, we use this very same filter language when we cover TCB dumps filtering options. So we should be well accustomed to the general syntax. And like with TCP dump, we won't be able to cover every single capture filter out there. But I'll cover the basic syntax with common examples and provide a reference to the documentation for more examples below. And so I'm just going to start up Wireshark once again. And capture filters should not be confused with display filters, which we're going to cover shortly. And so capture filters are much more limited and allow us to reduce the size of a raw packet capture. The latter or the display filters are used to hide some packets from an already established or captured packet list and offer a lot more functionality with specific columns and field names. And so obviously capture filters are set before we start a packet capture and cannot be modified during the capture. Display filters on the other hand, well, we don't have that limitation and we can just change them on the fly whenever we want. And so once we're back in this welcome screen here, well, we can find the capture filter itself just above the list of interfaces. And this is where we can actually specify and type in our capture filter. And if you remember, a lot of this is going to be mostly review from the TCB dump section. And so we have the primitive elements, right? So these include qualifiers like the host, right? If we want to specify a particular host. And you can see wire sharkark is giving us some useful indicators here on how we can complete the filter. And we also have things like port, right? If we want to specify a particular port, we can also prepend this with like source for source port. We also have various operators, right? So these include things like and or or not. And we can combine these or negate primitives that we covered to create complex filter expressions. So for example, if we only wanted to capture traffic to or from 8.8.8 8.8. Well, we can just type in host 8.8.8.8. If we wanted to capture traffic to or from a range of IP addresses, well, we can use the net qualifier here and we can specify that range or that cider notation. If we wanted to be more specific, we can specify the source net, right? So, only coming from a range of IP addresses. If we wanted to capture only DNS traffic, well, we could just use port 53. If we wanted to capture all Telnet traffic not from 10.0.0.5, well, we could specify port 23 for TNET and not source of the host of 10.0.0.5. If we wanted to capture any non-HTTP and non-SMTP traffic on a particular host, well, we could specify the host, in this case, example.com and not, and remember, we can wrap these in parenthesis here to specify port 80 or port 25. And I spelled and wrong. And the not in this case is used to make sure the negation applies to both port 80 and port 25. We can also get pretty in-depth and specify lengths in bytes and various payload signatures. And some of these examples will be found in the documentation link below. But the main takeaway here is that capture filters in Wireshark are used to limit the amount of traffic captured by specifying our criteria of the packets of interest. And we can also take a look at some more default examples by clicking the green bookmark option here. And if we have any filters that we use frequently, well, we can add them to this section as well. And so let's use that example.com example. So if I specify the host of example.com and not port 80 or port 25, well, I'm going to start capturing on ENSP03. And remember, your interface here connected to the internet might be different. So if I open up the terminal, I'm going to run netcat for www.agample.com. example.com and I'm going to try port 80. Well, we can see nothing was logged. In this case, I'll try port 25. I'll also add the verbose option here. No, we're still getting nothing. But what if I try a port that we didn't specify, like 1 2 3 4. Well, we can see in this case we did capture those packets. And so, let's quickly talk about saving a pecap file. So once we're happy with the packets that we captured, in this case let's say we are, we can go ahead and click on file save as, which allows us to save the current capture to a file on disk. And the most common formats that we can save the captures are is of course this.pcap file, which of course we're used to seeing through TCP dump. And we also have this pcapng file. And this is a more technically flexible and extensible successor to the default.pcap pcap file and is used as the default file format in Wireshark after version 1.8. But in this case, I'll just choose a pcap file. You can see we can name it as test.pcap and I'll just click on save. Okay, so once we have a pcap file, but we can simply load it into Wireshark for us as analysts to perform deeper analysis. And I'll mention again, Wireshark is not the best at handling very large pcap files. And sometimes it might actually be impossible due to the system freezing up and crashing on you. And so because of this, it's often a good technique to carve through a very large pcap file like a multi- gigabyte file with something like TCP dump using our lib pcap filters or just by making sure you have good capture filters in place initially to ensure we're not flooding our file with unnecessary noise. And so to open a pcap file in Wireshark, we can head over to the file menu here and click on open. In this case, I'm going to head to the pcaps folder within the wire directory and then click on this 2021-09-14.pcap file. And this is the file that we covered in the TCP dump analysis section of the course. And so I'll just double click on this file to open it up. And notice if we go back to the file tab here, we can also merge multiple pcaps together. And so with this option, we can actually merge multiple pcaps into a single file. And we can maintain the chronological order of each packet. And this could be really useful in situations where we've captured traffic from different sources or at different times, but we want to analyze them more cohesively. But in this case, we don't need to merge anything. I just wanted to showcase that option. And so now that we have a real pcap loaded in, let's talk about display filters. And so, as I mentioned before, display filters can be applied in the Wireshark interface after we've started capturing packets or after the packets have been captured. and they're used to only pull back or return specific subsets of packets that match our criteria. And while it's similar to the lib pcap language for capture filters, well, wireark provides a display filter language that lets us precisely control which packets are being displayed using multiple different columns and field names. And so we can check for things like the presence of a protocol or field or the value of a specific field or even compare two fields together. And so the simplest display filter is one that just displays a single protocol. And so to only display packets containing a specific protocol, well, we can type the name of the protocol into Wireshark's display filter toolbar. So to only display TCP packets, well, I can just type in TCP and hit enter. Similarly, to only display packets containing a particular field, well, we can type in the name of that field into the toolbar. For example, to only display HTTP requests, well, we can type in HTTP request. We can see it sort of has this object and value notation and so we can do things like comparisons as well. So we can build display filters to compare values using a number of different comparison operators. Right? So we have the equality or the equal filter and this is a very common filter where we can specify if a specific field equals a given value. For example, I can search for the IP address field or add and I can set if it equals a specific IP address, right? like 1 192.168.0.1. In this case, we won't return anything. But if I go back and choose one of these IP addresses here, like 103.232.55.148, well, we can see we're only pulling back conversations where that IP address is either the source or destination. We also have different operators like the greater than and less than or greater than and equal to or less than and equal to. And we're going to cover some of these as we start diving into more packets. We also have some really useful operators as well like the contains field. So in this case we can filter packets where the specified field contains a given value. Right? So for example I can do HTTP contains the word login. In this case it's going to filter packets where the HTTP payload contains that word. In this case we don't have any matches but in this case we can see this specific packet is making a get request to the service endpoint. So if I do HTTP contains service, well, we should pull back that exact packet along with any others that mention the name service. If you remember this specific packet capture, well, we identified the audiodg executable as an indicator of compromise. In this case, I can do a search for audiodg.exe. And you can see we're pulling back some relevant packets. And like with capture filters, we also have logical operators as well. So we have things like and or or not. And we're going to cover these in more detail as we start going through the analysis. And so these specific fields that we use are going to be dependent on what we're actually looking for, right? And there's an extremely large variety of fields and column names that we can use. And we're going to pick up on the most common and useful fields as we start to analyze pcaps. And so now that we covered the basic syntax in components, I think it's probably best to go through some examples. Right? So we kind of covered this already, right? If we wanted to only show HTTP traffic, well, we can just type in the name of the protocol. If we wanted to get more specific, well, we can specify if the request and the method of the request is equal to post and we can pull back any post requests. Similarly, we can change this to get to pull back any get requests. Instead of the method, I can also search based off of the URI. In this case, we can do contains audio DG. And again, in this case, we're pulling back any packets where if we dig into the HTTP or the hypertext transfer protocol, and if we look at the actual URI within the payload, well, we're going to match audiodg.exe. If we only wanted to pull back DNS traffic from a specific domain name like example.com, well, we can change this to DNS.query or qry.name equalsample.com. If we wanted to only pull back traffic from a specific port like port 80, well, we could run TCP.port equals 80. Another extremely useful and important option here is the ability to both prepare and apply filters within Wireshark. And so essentially any piece of data that we're looking at within Wireshark, whether it be any of the columns here or any of the fields and columns that we can extract from the packet details itself. For example, let me open up an HTTP request here. Well, we can right click on the specific entry or value or the column and from here we can either select apply as filter or prepare as filter. And if we choose prepare as filter and click selected, well, you can see it's going to add the relevant matching syntax to the display filter but not actually run the filter yet. If I rightclick this again and click on apply as filter, well, this is going to immediately filter the packets to what we selected. Right? Right. So in this case, we're pulling back the specific packet where the URI contained /service. And in my opinion, this is the best way to learn how to create and edit display filters in Wireshark. So feel free to play around with some of these filters and conditions and field names. In the next lesson, I want to talk about statistics within Wireshark, which are another absolutely invaluable way for us to break down and make sense of a daunting and large pcap file. And then we're going to finally walk through and highlight some additional analysis strategies. And so I'll see you in the next video. In addition to display filters that can help us isolate interesting traffic that we're looking for, well, wireark offers a robust set of statistical features to analyze captured network traffic from a high level and is one of the most important features we have available to us when it comes to making sense of a large pcap file. And in my methodology, the statistics in Wireshark is the best way to start our analysis because it will provide us with all the highle guidance and overview that we need to start drilling into things like interesting conversations and top talkers and protocols of interest, which we'll get into. And we can find all of these statistics, of course, under the statistics tab in the top menu bar. And you can see there are a lot here, and we're not going to cover every single one, but we'll cover the most important and useful statistics that are going to help us for quick wins. And so let's start out with the first one here or the capture file properties. And so if we click on this, you can see we're going to be brought to this window pane here. And this is going to open the capture file properties pane, which is going to cover a lot of useful information and metadata about the packet capture itself. Right? So the file tab here, right? So under file here, we can see things like the name and the Shaw 256 hash of the actual pcap itself. Under time here, we can see the time stamp of when the first packet and last packet was delivered. as well as the elapse time between the first and last packet. In this case, we have about 9 minutes. And this is going to be very useful for us because we can use this section to confirm that the pcap we're looking at contains the actual traffic that we're looking for. Right? So, if we're handed a pcap file in an alert, well, we need a way to confirm with the client or the stakeholders that the file we're about to investigate and spend time analyzing actually contains the traffic from the time frame of the incident. And so we can avoid a lot of wasted time and resources by checking the time of the first and last packet. We also get various well statistics as well. Right? So we can see the total amount of packets that were captured in this file. And if we had a particular display filter set, well, we can see the amount of display packets as well. For example, if I close this and just run HTTP as our display filter and head back to the capture file properties, in this case, we only have 86 packets or 2.3% of the packets that match with the HTTP protocol. And so, next, let's look at resolved addresses. And in this case, we can see wherever a DNS lookup was performed and an IP address was mapped to a domain. And so as we start scrolling down here, well, we're going to start to see some IP addresses on the left here and the associated or resolved names over on the right. And the hosts that are populated here are typically taken from the DNS answers within the capture file. And so this saves us a lot of manual work by looking through different DNS queries and responses. And so next here we have the protocol hierarchy. And as the name suggests, well, this window pane here presents a hierarchical view of the different protocols encountered within the captured traffic. And it displays statistics and calculations like the number of packets and the bytes and the percentage of bytes as well. And so using this, we can easily identify which protocols are predominant within the traffic and figure out some quick wins on if we can see any high volumes of traffic on a suspicious protocol or identify any protocols that might have unencrypted connections that could benefit us as we dig into the payloads more easily. And one important thing to note is that it's going to use the current display filter to aggregate this data. In this case, we're returning a 100% of the packets as HTTP, which isn't the case for this pcap file. So, if I remove the display filter and run this again, well, you can see we're starting to see some more protocols here. In this case, we do have some HTTP traffic, but we also have a lot of TLS or HTTPS traffic as well. So next let's look at conversations and the conversation statistics feature will organize traffic based on the communication between endpoints like IP addresses and ports and it provides details like the number of packets and bytes and the packet rate for each conversation. And so by using this well we can analyze communication patterns and identify things like the top talkers or the most predominant talkers on the network. And for example, this can be really useful as we can potentially see if an internal IP is reaching out predominantly to an IP we don't recognize or perhaps one IP address is making a large number of requests to a number of different IPs and maybe we're dealing with a port scan. And so if we click on the IPv4 tab here, well, we're going to get all the IPv4 statistics. And in this case, we can click on bytes two times so we can sort it in descending order. And this gives us a general breakdown on who was talking or communicating with what system the most. In this case, we can see this internal address of 10.0.0.168 communicating with 103.23255.148. And we can see the amount of packets that were delivered from A, so address A to address B or the packets that were delivered from address B to address A. And if we notice an interesting conversation here that we want to dive into in more detail. So for example, this top one here. Well, we can right click on the conversation and what do you know? We can prepare or apply it as a filter. Well, we can choose which direction we want to specify for the traffic, right? Do we want to look at either A going to B or B going to A or only A going to B? So this gives us a lot of easy options to filter off of. For example, if I click on both A and B, well, you can see the display filter that it immediately applied. And so I'll just clear that out. And next, if we look at the endpoints tab here, well, this is going to give us insights on the individual host network activities like the network traffic sent and received and the packet count and data size. And if I click on IPv4 again, well, we can get a list of all of the different endpoints that are included within this pcap file. And this is kind of similar to what we were painstakingly doing manually with TCP dump when we were piping things to cut and sort and unique to pull back and aggregate the top talkers. In this case, I can just click on bytes here to sort the amount of bytes or the amount of packets in descending order. Lastly, here we can also go down to HTTP and look at any of the requests that were made. And so with this option, we can see all of the different HTTP requests that were made to various servers and URIs all in a very nice and easy to understand chart. Right? So if we scroll down here, well, we can see this 103.232.55.148 address. And we can immediately see the audiodg.exe endpoint that was accessed. And so this can be a very quick win for you if the pcap file you're analyzing contains a lot of unencrypted HTTP traffic. And so moving on, we'll touch on this some more later, but Wireshark allows us to aggregate and rebuild an entire stream of protocol specific packets like TCP or HTTP. And in doing this, we can understand the whole picture a lot better. And this is something we tried our darnest to do with TCP dump alone. But Wireshark just makes this so simple for us and is such a powerful option when we want to see the entire conversation. For example, I'm just going to filter on HTTP traffic. And in this case, I'm going to choose this packet here, packet 1186. And if I right click on the packet and go down to follow, well, I can follow either the TCP stream or the HTTP stream. And since the HTTP stream is going to contain more details about the HTTP payload, well, I'm going to click on this, and we're going to be brought to this amazing pane here that is going to show us the entire conversation between the two endpoints. And so we can see that all of the requests here are in that red color and all of the responses from the web server are in blue. And so we can see all of the headers as well as any of the body content. Right? So we can actually reconstruct this web page if we really wanted to. And again, this can be very useful in investigations when you're dealing with an unencrypted payload. We can also either select the entire conversation or only the requests here or only the responses, right? So we can filter this more if we wanted to. And so I mentioned packet numbers earlier. Well, each packet captured in Wireshark is going to be assigned a unique sequential number. And this packet number serves as an identifier and is displayed in the packet list pane as you can see here. And these can be really important for us in terms of referencing and analysis, right? So we can actually track and log and reference specific packets during analysis and document them accordingly because these packet numbers are chronological and sequential and so they're not going to change if we start applying things like display filters. We also have some useful navigation options around the packet numbers themselves. For example, I can click on the go option here in the main toolbar and click go to packet. In this case, I can type in a packet number. For example, I'll type in 1,250. And if I click go to packet, well, it's going to immediately highlight this packet number for me. And this can obviously be very useful when we want to pinpoint and find a particular packet by its number. We can also mark specific packets as well. So if I right click on any of these packets, I can click on mark packet. Alternatively, with a packet selected, I can press CtrlM and it's going to mark that packet for me. And after doing so, I can go up to the display filter and type in frame.mmarked and set that to equal to 1 to only display marked packets. And so obviously this can be very useful for tagging a packet for later review. And so lastly here we can export various objects that are found within our packet capture directly out of Wireshark. And this is another extremely useful feature here because you can think of the scenario where a user suspectedly downloaded malware like an executable or a malicious PDF or a word document. Well, if the connection was over an insecure protocol like HTTP or an unencrypted FTP server or an SMB session or if we were doing some sort of TLS inspection and had our own trusted CA or encryption key log file, well, we could potentially decrypt the data over HTTPS as well. And by extracting these files, we can do analysis that we're already quite familiar with. So we could extract the hashes of these files and compare them against malware databases like virus total. Or we could actually submit these files for dynamic malware analysis. Or in the case of a PDF or office document, we could carve into them and extract any malicious scripts or embedded objects. And to do this, it's honestly quite simple. I click on file here and I can go down to export objects. And you can see various protocols here that we can search off of. In this case, since we have a lot of HTTP traffic, well, I'm going to click on HTTP and we can see all of the different files that were sent over the wire. Particularly, we're aware of the audg.exe file. And if we scroll down, well, we can find the actual file itself. And so, in this case, with it highlighted, I'm going to click on the save option. And you can see I can actually save and extract the file from the pcap file itself. And so if I click on save here and back in the terminal, I can run an ls with the tac a flag because remember it was saved with a dot at the beginning of the file name. Well, we can see the audiodg.exe file. And of course, I can run a file on that file and we can see it's a PE32 executable. And I of course can run the Shaw 256 sum of the file as well. And if I copy this file hash, I can search for it on virus total. And we can see 52 out of 72 security vendors and four sandboxes flag the file as malicious. And so in doing this exercise, we can really see how useful Wireshark is for performing more detailed inspection. This is just something we could not really have done with TCP dump. And so now the past few lessons did really contain a lot of information and syntax and options. So let's take a step back and put all of what we learned together and run through a sample PCAP in the next lesson. And so I will see you in the next video. Now that we've taken in quite a bit of information, let's walk through the general process for effectively analyzing a pcap in Wireshark. And the methodology we cover here can easily be applied to any packet analyzing solution or tool. But in our case, Wireark makes all of this very easy for us with its visualizations and statistics. And so, let's get right into it and open up Wireshark. And in this case, I'm going to click on file and open. And I'm going to select the 2023-2-3.pcap file. And this is a public pcap exercise that was provided by malwareanalysis.net net and Palo Alto Network's unit 42 which is a fantastic resource for PCAP samples that I'll cover in the additional practice lesson and so all credit goes to them for this sample and so first once we have the sample open the first thing I typically do in an investigation is to set up the timestamp so I can document consistently with a common reference format and so to do this we've already technically done it in the previous lesson but I'll click on view here under time display format and make sure that I have UTC date and time of day selected and we could choose a Unix time stamp as well or that epoch time. But for readability, I'll choose this option. And depending on what time stamps we have available to us, either through the alert or a ticket, we might need to modify or shift the time format slightly to correlate things correctly. But in this case, the default UTC will work nicely for us. And so next, let's follow our methodology, right? So we can start from a high level or a zoomed out overview and then highlight any interesting conversations or end points to focus on as we go through the pcap file. And so to do this, what we can and we should leverage Wireshark's statistics. And so first I will go to capture file properties. And we can see that we have over 50,000 packets captured within this file, which is quite a lot. And so this is why it's so important that we start from the top and drill down as needed. If we look under the time here, well, we can see that the elapsed time between the first and last packet was almost 3 hours, between around 12:00 p.m. to 2:45ish. And so again, this can be very useful information to confirm before we start diving in and investing resources and time into analyzing a file that doesn't contain the relevant data. And so next, let's go down to conversations. And from here, if I click on the IPv4 tab and click on packets A to B and filter this on the most amount of packets, well, we can see that 10.0.0.149 communicated the most with 10.0.0.6. And so we can make note of this 149 address as our likely culprit for the victim because all of the traffic originated from this IP address. And we can see that it's communicating the most with this 6 address which is another internal IP address on the same subnet as the victim with most of the traffic heading in one direction. So we'll make note of that for now. And we can also note some of the other top talkers. Right? So we have 208.187.122.74. We have 78.3167.7. We also have 5.75.25.43. And so next, let's take a look at the protocol hierarchy and look at the most common protocols and see if we can identify any lowhanging fruit or quick wins to base some more detailed analysis off of. And usually what I like to do is close all these arrows here to make it more easy to look at. And interestingly, we can see we have a lot of net bios and SMB and LDAP and RPC, even SMTP and ARP communication as well with a small number of HTTP traffic with only four packets. And since it's unencrypted, we only have four packets. So, let's start looking through the small amount of HTTP traffic to see if we can find where any potential malicious traffic originated from. And so first let's set up some additional columns to show the source and destination ports which are not enabled by default within Wireshark. And so we can do this by clicking on edit and then go down to preferences. From here we can click on columns. And so to add a column we can click on the green plus icon here. And in this case we can set a title. And so I'll just call it source port. And for the type here well we have this drop down menu. In this case, I can go down to source and find source port unresolved. Next, I can add a second column for destination port. In this case, I'll just call it desk port. And under the type here, again, very similarly, we can click on desk port here, unresolved. And just to make this easier to look at in the columns view, I'm going to drag this up right under source. So, we have the source IP address and then the source port. Similarly, I will drag the destination port here, right under destination. And feel free to name these whatever you like. Once we click okay, well, we can see our screen refreshed here. And we now have the source port and destination port. And so we wanted to look at HTTP traffic. So let's add a display filter to just select that protocol. And in doing this, we can immediately identify those four packets. And so let's open up the HTTP packet details for this first packet here. We can see an interesting result here. The host value in the HTTP request header is an IP address and not a domain name, which is immediately suspicious to me. If we go up to the get request here, well, we can see it's making a request to 86607.dat. And so, it's making a get request to a DAT file, which is also very suspicious. It almost feels like that Mr. Robot episode where Elliot finds the DAT file. And so, let's open up this stream. So, I'm going to right click on the packet and click on follow and then HTTP stream. And in this case, we're going to start rebuilding the conversation. And in the actual header of this request, we see some even more suspicious information. Under the user agent, we have curl, the curl utility. And typically, an end user would never have curl as their user agent unless they've executed some sort of script either knowingly or unknowingly. So again, this is very suspicious. And if we look at the actual response from the server where it's sending over this attachment or this downloadable file, well, we are seeing that common string here of this program cannot be run in DOSS mode. Additionally, we have MZ here as the magic bytes or the file signature at the very beginning of the file. And if I go to Google here and just search for list of file signatures, well, we can get a list from Wikipedia here of all the common file signatures and what they mean. And these file signatures are also known as magic numbers or magic bytes. And they typically tell operating systems what kind of file to present. For example, if I search for a JPEG, well, this is the magic bite or the magic file signature you'll find at the start of a JPEG file. And this is what it looks like in hex. So if I do a search for MZ here, well, we're immediately seeing this is a DOSS MZ executable. And if we click on this, we can see the actual MZ stands for the creator of the DOSS program. I think it says it here. Yes, we can see this hexadimal string here or this MZ are the initials of Mark Zikowski, one of the leading developers of MS DOSS. So in this case, the endpoint here or the victim downloaded an executable file from this web server using the curl utility. And if you remember, we could have actually found this using the HTTP statistics here under requests. You can see immediately we are finding this 86607.dat file. And so let's continue gathering IoC's. So specifically we have the name of the file and its URL and the IP address that is associated with hosting it. But let's also extract the file itself so we can gather its hashes. And so of course if you remember to do that we can go under file export objects and click on HTTP. And in this case we can see there is a certificate here which we don't really need to worry about. But we do have this file. And if I highlight it and click on save, well, we can save it to our folder here. And so now that we've extracted it, I'm going to back out of this directory where I saved it. I'm just going to run a file on 8667.dat. And we can see, of course, it is a p32 executable. In this case, a Windows DL file. And I can simply run Shaw 256 sum to get the hash of the file. And of course, we want to make note of this in our documentation and in our ticketing software. And so now it's just a matter of doing file reputation checks that we're very used to doing already from the fishing section, right? So we can check virus total and paste in the hash. And of course it's being flagged. We can check the malware bizarre database in this case under search syntax here. We can see that we can specify a SHA 256 hash using this syntax here. And if we run that, we can see we have a match in this case to Quackbot. And so it looks like this file hash is associated with the Quackbot malware family. And so we've successfully identified a number of IoC's that resulted in the infection of the victim machine here. We've also determined through our analysis and research that the specific type of malware is Quackbot. And so let's do some more research into Quackbot and see if we can discover any post compromised IoC's or tactics that we might be able to additionally identify in our PCAP sample. And in this Sofos article here, they discovered an infected host performing an ARP scan on the internal network to discover if there are any other active IP addresses that they could maybe pivot to. Very similar activity here in this Canadian Center for Cyber Security alert in which they've identified CACbot performing an ARP scan in order to discover other endpoints on the network. Specifically, they're mapping it to MITER T1016. And we're going to get into the MITER attack framework in a lot more detail in the threat intelligence section. But if we look at the actual software categorization of CACbot itself, well, we can see associated techniques used particularly under the technique of T1016. Well, we can see another reference to using ARP. In this article here, we can see that it was using SMB protocol to spread across a network. And in this scroll article here, we can see that it was also discovered exfiltrating emails in an email thread hijacking attack. And so if you recall, along with IP and TCP traffic, we did actually see a large amount of ARP traffic in our protocol hierarchy. And so with that in mind, we can check our PECAP for any indicators of an attacker performing an ARP scan from the compromised victim device. And an ARP scan or an address resolution protocol scan is a technique that attackers commonly use to identify active IP addresses within a compromised network. And so these scans operate at the MAC address layer where a device will send ARP queries to the broadcast MAC address. And the purpose of these queries is to discover which IP addresses respond and are currently in use or active within the network segment. And so an ARP scan will typically involve a client sending ARP requests to sequential IP addresses within a network. And so if we start seeing some sequential queries, this will be a telltale sign of an ARP scan and suggest that an attacker might be attempting to map out the network by identifying which IP addresses respond. And so to find this traffic, well, we can use the following Wireshark filter. In this case, we can filter on the ARP protocol. And additionally, we can look at the Ethernet destination of that broadcast address. And the broadcast address is two Fs with a colon six times. And so if we run this, well, we can immediately see all of these broadcast queries, right? So if we look under destination, it it is to the broadcast address. And if we look under the info column here, well, this is basically the query that is being asked through the address resolution protocol, right? So who has 10.0.0.248? And they're asking tell me as the host address here. And as we scroll down, well, we can see the IP addresses are descending. And this is a clear indication of an ARP scan. And at this point, we can infer that the attacker who compromised the machine was attempting to find any other active machines within the network to potentially probe or move laterally to. And so, if an attacker manages to identify any active IP addresses within the network, well, they'll likely attempt to ping these systems to see if they're alive and if they can get a response before performing additional port or service scans. In this case, we can use the ICMP filter to see if we can find any ICMP echo requests or replies. And in this case, we have four packets, two requests and two replies. Interestingly enough, it looks like the attacker managed to identify 10.0.0.6 as well as 10.0.0.1. And so we can also check if the attacker performed any kind of port scanning on these identified IP addresses to see if there were any lateral movement or post compromise actions that they might have performed on them. In this case, I'll change the display filter to IP.ADR for address and set that to equal to 10.0.0.1. 0.1. And if I run this, well, we can identify a number of ports that the attacker tried probing on the 10.0.0.1 endpoint. By the looks of it, we can see a number of incomplete TCP handshake attempts and a number of reset flags that were set as well. Specifically for port 445, 139, and port 80 as well. And so when we were looking at the protocol hierarchy, we also saw some SMTP traffic. And considering this is unencrypted traffic, we can also take a look to see if we can uncover anything interesting. So in this case for the display filter, I'll choose SMTP in which we get a number of packets returned. And if I scroll to the top under info, I can see an authentication login packet. So this is interesting. So I'm going to right click on this and click on follow TCP stream. And in this case, we can get an entire conversation view of what was received in blue and what was sent in red. Particularly we can see under the off login here some B 64 encoded data and so what I'm going to do is copy this entire conversation here of B 64 data for this authentication login and I'll head over to the ever useful cyersh I'm going to paste in that conversation here and just clean it up a bit by removing these numbers and now I'm just going to drag over from base 64 and we can immediately see the username that was entered with this email address as well as the password that the attacker tried as well. And in this case, it looks like the authentication failed. However, we might have identified some potentially compromised user credentials. And obviously, we don't have the organizational context here, but this kind of thing is of course worth noting as well and might expand the scope of the investigation. And so a very common goal for attackers once they gain access is to perform actions on objectives and excfiltrate data from a compromised system or abuse services in some way to escalate privileges and gain access to an active directory domain controller. In both cases, this can typically be done through SMB or the server message block protocol which enables file transfers between Windows hosts. And in an AD environment, Windows hosts and servers will commonly communicate with the domain controller as part of normal system operations. However, certain types of activity like file transfers over SMB can be suspicious. And fortunately, Wireshark makes it very easy for us to view objects transferred over SMB. And like we did with HTTP, well, I'm going to head over to file under export objects. In this case, instead of HTTP, I'm going to select SMB for server message block. And so at the top here, we can see a number of files related to group policy objects or GPOS as specified by GPT.in. ini or gpt tempmplate.inf. And these files are actually quite common to see in an active directory environment and they allow administrators to manage settings and configuration centrally for users and computers within the domain. But Windows executable or DL files within SMB traffic can be very suspicious. It could also be benign, for example, in the case of Windows Server Update Service. But randomly named DLL files like these are pretty suspicious and warrant further investigation. And it looks like we have six potentially suspicious DLL or DL.cfg files and they were all transferred to the 10.0.0.6 host. And in the case of this PECAP file, well, I'll pull the curtain a bit here and say the 10.0.0.6 is the domain controller of this network. And typically when investigating a file like this, well, we would know the IP address of the domain controller as well. And so what I'll do is go up to text filter here, and I will just search for DLL. And this will list just the six files here. And I will just save each of these files one by one. And I'll just make a directory for them called SMB. Then I will move every file with a DLL into the SMB folder. And from here I'm going to run a file on all of these files. And we can see that half of them here are in fact Windows DLS. And all of the CFG files here appear to just be data binaries. And so if I run Shaw 256 sum on all of the files as well, well, we can see that all of the DLL files all have the same hash. And if you did note this in your documentation, well, this is the exact same hash of the initial CACbot DLL file that we discovered over HTTP at the beginning of the infection. And so in a real world scenario, we would typically want to direct our focus now to the system or the host that received this malware. In our case, the 10.0.0.6 or the domain controller. And we would do this either through our SIM system and correlate logs that way or through various EDR logs or additional PECAPS from this host itself as it seems very likely that the attacker attempted to move laterally and continue compromising the network. And so to sum up our analysis, we were able to start from a highle view and look through our statistics and conversations and protocols in order to carve through the pcap and focus on interesting packet streams and lowhanging fruit to discover the initial vector of malware infection and compromise. And as we started to identify the specific type of malware infection that we were dealing with, we were able to identify several post compromise artifacts and indications of host discovery and lateral movement within the network. There were also a number of other indicators associated with CACbot within this pcap file itself related to things like TLS certificates and VNC activity. However, those investigations are a bit out of scope for this section, but I will include the write up from unit 42 if you'd like to investigate them further. And admittedly, this was quite an involved walkthrough and I wanted to cover all of the important methodology steps and features that we have available to us as analysts within Wireshark. And obviously we can't cover every single scenario and indicator that you might come across in the field. Which is why it's more important to build up a methodology of approaching pecaps from a high level first and leveraging things like statistics and aggregations to identify interesting conversations and top talkers or IP addresses. From there we can zoom in and do more in-depth analysis on these conversations, right? Like what protocols are they speaking? What ports are they talking to? Can we follow any of the TCP or HCP streams? Or what objects can we extract? Right. And so as we identify more information and start putting the puzzle pieces together, we can zoom back out and identify other hosts or conversations of interest and repeat the process. And so in the challenge following, you'll be put to the test to see if you can complete a network traffic analysis investigation on your own. But don't worry, I will be here the whole way if you need a walk through. And so with that, I will see you in the next video. Now that we've gone through network traffic analysis, let's shift our focus over to network intrusions and how we can detect and prevent network threats both proactively and reactively. As I've mentioned earlier in the course, intrusion detection systems or IDS and intrusion prevention systems or IPS are important components in network security that SOCKS use to proactively monitor and actively prevent network intrusions and attacks. And so at a high level, an IDS or an intrusion detection system is a device or a software application that monitors the network or system activities for malicious traffic or actions or policy violations based on predefined rules or known malware signatures or through things like anomaly and behavior-based detection. And IDS's are primarily designed to alert and identify and report any of these policy violations. And they can do this through monitoring and analysis. Right? Right. So, an IDS is going to continuously monitor network traffic and actually do things like open up and analyze data packets and log files to detect abnormal patterns that might indicate a potential attack. And when suspicious activity is detected, well, these IDS's can generate alerts and notify the sock of potential threats. And these alerts can be configured to provide detailed information about the nature and the source of the threat or the network or the endpoint and could potentially conduct some automated IoC extraction. And typically all of these alerts will be forwarded to the SIM system. And the information that will be forwarded will be through logs. So an IDS is going to log all of its monitored events which can be very useful in investigations or incident response scenarios and will assist us with things like correlation and compliance reporting and also provide future threat detection capabilities with the IoC's and signatures that it detects. And typically an IDS is going to be deployed out of band. So essentially not in line with the network traffic. This is because it doesn't need to sit in between and actually intercept and drop specific packets. It can do all of its monitoring passively. And since they operate passively, well, they're a lot easier to scale and less of a burden on the network performance and throughput since there isn't that single choke point of having an ID system in between traffic. On the other hand, an intrusion prevention system or an IPS is more of a proactive security solution that's designed to detect and prevent identified threats in real time. And so unlike an IDS, which is primarily a monitoring and alerting tool, well, an IPS can take a step further and actually take immediate action to block or mitigate malicious activity as it's occurring. And so it does this through traffic inspection. So an IPS is going to inspect all of the network traffic at a deeper level and actually analyze packet contents as it sits in between the traffic and intercepts them. And when it detects suspicious activity or anything that violates its predefined rules, well, an IPS can block the offending packets and actually drop them from the network and prevent them from reaching their intended destination. And similarly, they can terminate connections that are deemed harmful or anything that goes against its rules, which can stop any ongoing attacks. And similar to an IDS, well, an IPS can also generate alerts and log events for any analysis and recordkeeping purposes. And so an IPS is typically going to need to be deployed inline because it needs to actively inspect and control the traffic flow. And so a consideration here is that it can actually introduce some latency since it needs to actively process and filter traffic in real time. And so diving even deeper, well there are two main types of IDS or IPS systems. And the first here is a network-based IDS or IPS. And these systems will operate of course on the network level. And so they can inspect and analyze all of the traffic flowing through the network. On the other hand, we have hostbased ids and IPS systems as well. And these operate as the name suggests at the host level and they can focus on individual systems or endpoints rather than the entire network. And so these appliances can monitor activities on the actual host. So things like file system changes or login or application behavior. It can look into processes being spawned or files being accessed or any registry changes. And of course, in these cases, well, it can alert and log and actually block malicious host actions from taking place. And so with all of these network and hostbased IDS and IPS appliances, well, we often have various means for detecting and preventing threats. For example, we have signaturebased detection. And this involves comparing network traffic or host activities against a database of known attack patterns or what we call signatures. And when a match is found, an alert can be triggered indicating a potential threat. And so signature-based detection is really effective at identifying known threats, but it can struggle with detecting things like zero days or variance of known exploits because it's comparing all of its data against a database. On the other hand, we have behavior-based detection. And behavior-based detection focuses on identifying abnormal or suspicious behavior within a network or a host. And rather than relying on predefined rules, these systems analyze deviations from a normal pattern of activity or a baseline. And so because it's not focused on hard-coded signatures or rules, well, it has a better chance of detecting previously unseen threats because it's looking at the actual behavior on the endpoint or the network itself. But the key here is that you need to have an effective baseline in place. Otherwise, these systems are prone to generating a lot of false positives if the normal behavior is not accurately defined. We also have rule-based detection. And so rule-based detection, as we've talked about earlier, involves the creation and enforcement of specific rules or policies that can govern acceptable network or host behavior. And so rulebased detection is highly customizable, right? So we can tailor it specific to the security requirements of our organization. The downside here is that it requires a lot of upkeep and maintenance to remain effective against ongoing threats. And so when we look into Snort in the next lessons, we're typically going to focus here on rulebased detection. And the last thing I'll cover here on the slide is the diagram on the right. And this is what's referred to as the known unknown matrix, also known as the Johari window. And this is a framework that's used to understand the knowledge about information and how we actually categorize it. And so in the context of a sock, it can help us categorize and understand different types of threats and detection methods. Right? So this matrix is obviously divided into four quadrants. And in the top left, we have the known known. And these can be thought of as threats or vulnerabilities that are both known to the organization and attackers. And so information in this quadrant is well understood and documented. And our defenses can be specifically tailored to address these threats. And in the top right, we have the known unknowns. And these are threats or vulnerabilities that are known to the organization but not necessarily to the public or to the attackers. And this can include things like internal vulnerabilities that the organization is aware of but have not been exploited yet. In the bottom left we have the unknown known and these are threats or vulnerabilities that are known to the attackers but not the organization. And obviously this is a critical area to focus on as it represents blind spots in our organization defenses. And lastly, we have the unknown unknowns. And these are threats that are unknown to both the organization and attackers. So these can be new emerging threats or zero-day vulnerabilities that have not been discovered yet. And so to completely generalize this nuanced concept that probably shouldn't be generalized, well, we can think of signaturebased detection as highly effective against known threats. So the known known, but it kind of fails against unknown threats. On the other hand, behavior-based detection is really good at identifying anomalies. And so, it's really good at detecting known unknowns and some unknown knowns, but it can also generate a lot of false positives. And lastly, rulebased detection can balance known and unknown threats, but struggles on completely new threats because it relies on predefined rules. Okay, let's shift our focus and talk a little bit about Snort. And so Snort is an open-source network-based IDS and IPS system managed by Cisco and it's a pretty popular choice in the industry and is also integrated into a number of security solutions as well primarily due to its effectiveness in real-time traffic analysis and packet logging capabilities. And so Snort is really versatile and is capable of detecting a wide range of network attacks and probes. And we also have the power to ingest a wide range of community curated rules and also create our own custom rules. And so the list is basically endless when it comes to what we can detect with Snort. And so Snort was originally created back in 1998. And since then, it's evolved into one of the most widely deployed IDs and IPS solutions globally. And over the years, Snort has undergone more and more development and has gained a large community of developers that are maintaining the rules to keep Snort's detections up to date with the latest and greatest attacks out there. And so, the two major versions of Snort in use today are the more common Snort 2, but also Snort 3.0. And there are some notable differences between the two like multi-threaded support and scalability improvements and also different configuration systems using Lua and Snort 3. But in these lessons, we'll focus on Snort 2 due to its widespread use and accessibility of rule sets and also detailed documentation and also the likelihood that you'll encounter it in professional environments because not every organization or security solution has begun migrating to Snort 3. And so having a familiarity with Snort 2 is very useful to have and will give you a great foundation to migrate if needed. And so Snort can operate in three primary modes. The first is the sniffer mode. And so in this mode, Snort is going to read network packets and display them on the console. And so this is very similar to TCP dump with a bit more functionality. So something like T-Shark or Wireshark in the command line as well. The second mode is the packet logger mode. And so again like with TCP dump, Snort can log the packets into files on a disk. And so of course this is obviously useful for us if we want to do offline analysis later on. And so the third mode is the most advanced mode and the mode that we'll focus on in this course is the network intrusion detection and prevention mode. And so this is where Snort actively monitors the network traffic against defined rules and can take actions like generate alerts or block or drop traffic to prevent potential intrusions. And these predefined rules can be ingested through community rule sets or through threat intelligence capabilities or developed in-house with custom rules which we're going to take a look at. And so rules really are the main core of how Snort operates. And similar to firewall rules, Snort rules allow the system to inspect network traffic and then make decisions or take actions based on the criteria. And so let's go ahead and install Snort for the first time. And so I've just opened up the terminal. And in this case, I'm just going to run pseudoapp install snort and then hit enter. You might need to enter your password here if you haven't done so already. And when we're prompted here, we can just hit capital Y and hit enter. So when we're installing Snort, you're going to see this configuration screen pop up. And so in this case, it's asking us for the address range of our local network. And so this is going to depend on your current VM setup. And so to find out this information, I'm going to press control shift and t to open up a new terminal tab. And in this case, I'm just going to run the if config command. You can also use the newer IP command to figure out the same information, but I guess I just have old habits here. And if I look under my ENP03 interface, again, yours might be named differently, but I can see this inet of 192.168.1.4 and this is my IP address. Additionally, I can see the net mask here or the subnet mask of 255.255.25. 255.0. And so this means I am on the 192.168.1.0/24 network. And we could also run the IP command and give it the A and the S argument. And in this case, if we look under ENTP0S3, well, we will see 192.168.1.4, which is my IP address, as well as the slash notation or the cider notation of the network that I'm on. So, in this case, we can copy this, but make sure if you're on a /24 that you change this to a zero. And so, I'm going to head back over to my screen here with the configuring snort window and just type in the address range for my local network. And from here, I can just hit okay. All right, it's successfully installed. So if I clear this and then run snort with the tactac version, well you can see I'm pulling back version 2.9.20. And we can also see that along with the installation, it made sure we had the following dependencies. So we have lib pcap here. And we're actually used to seeing this dependency because this is the interface for user level packet capture and it gives Snort the capability to capture network packets which of course Snort needs to inspect and analyze the traffic. And we're already used to this library from using TCP dump and wireshark. We also have PCRE here and this stands for Pearl compatible regular expressions. And so this library or package gives us the ability to use things like pattern matching and regular expressions within our snort rules. And lastly here we have zib and this is just a compression library used for data compression and decompression. So before we jump into the configuration files, in a typical organizational deployment, well, Snort's listening network interface will operate in promiscuous mode. So it can effectively monitor and analyze all of the network traffic. Promiscuous mode is a network interface configuration where the network card captures all of the packets on the network regardless of their destination address. Right? So normally a network interface card or a nick is only going to process packets addressed to it. If we turn on promiscuous mode, well, we can actually process and intercept and log all of the network packets traveling through the network, even if they're not destined for our IP address. But we don't really need to worry about this configuration at the moment because for this lab exercise, we're going to keep everything local to simplify the setup and avoid us needing to spin up multiple VMs. Okay, so I'm just going to clear this out. And so the main configuration files that we need to know about to use and operate and well configure Snort are typically found in the Etsy/Snort directory after we install it. So if I just CD over to that directory, it's under Etsy and then Snort. And if I run an ls with an al, well, we can see a number of files and a directory here for rules. And so this snort.com file, this is the primary configuration file for Snort. and it's going to define all of our main settings and components and variables for Snort's operation. And we also have this rules directory here. And so this directory contains all of the predefined rule files that Snort is going to use to detect specific patterns of malicious activity. So if I run ls with attack a under the rules directory here, well, we can see a large list of default rules that come shipped with Snort. For example, if I just cat out one of these files, for example, I'll pick the backdoor.ules rules file. Well, we can see a number of rules that have been defined. And this might look like gibberish at the moment, but we will go through the structure of a rule. And we're going to look into writing our own rules as well. And so before we do anything, it's going to be best practice for us to make a copy of the configuration file in case we make any mistakes or if we want to revert back to the default configuration in case we run into issues. And so if you remember snort.com is the main configuration file. We can also see that only root can read and write to it and only members in the snort group can read this file. And so if we want to make a copy, we're going to need to run pseudo. And then I'm just going to provide the copy command. In this case, I'm going to copy the snort.com file and I'm just going to name it snort.com.back or bak, which is a common syntax for backup files. So you can see here we have this configuration backup file now. So now let's open up the configuration file and take a look around. And to do this I'm going to run pseudo and then nano snort.com. And we're now taking a look at the configuration file. And if we scroll down we can see all of the different things that we can set and configure within this file. So we can set things like the network variables or the decoder information or base detection engines or pre-processors or output plugins. Under seven here we can customize our rule set which we're going to do in a second. First here I'm going to scroll down to set the network variable section or step one here. And so this is where we can specify the subnet that Snort is going to monitor. And if you remember we actually did this and we configured our home network while we were installing Snort. So in my case that /24 network that I provided is set to the home net variable. And this any statement here means that the variable will include all of the IP addresses in the network range. And so we could just leave this as is. But if we wanted to change this value or hardcode it, well I can just delete the variable here and put 192.168.1.0/24. Similarly, we have the external net variable as well. And as the comment says here, we can just leave this as any. And the reason being is that we ideally don't want to confine the external or internetf facing network space to a particular subnet as of course attacks can come from anywhere. And so we don't want to tell Snort to only consider a specific network range as external. And we could leave all of these remaining variables just as they are. But essentially, if we wanted to, we could list specific hosts or IPs that relate to critical or important servers or resources on the network, right? like HTTP or web servers or email servers or DNS servers. And at the bottom here, we can see this rule path variable which currently points to etsy/snort/rules. And this was the rules folder that we were quickly taking a look at. And so we can just leave this as is because this is where we're going to place all of our custom rules. And so I'm going to scroll all the way down now to section 7. And in section 7, this is where we can customize our rule set. And this first specification here, you can see we're including our rule path and then the local rrules file. And so this is a specific file name to contain and write all of our custom rules in. And as we scroll down, we can see a number of rules in white here that have not been commented out. And so these are active rules. And anything in blue here or with the pound sign at the beginning of the line, well, these rules have been commented out or deactivated. And so Snort is not going to look at any of these rules, but it will parse through and look at these rules. And so because we want to start writing custom rules and learn how we can write custom rules, well, we don't want these default ones getting in the way. And so let's go ahead and comment out all of these default rules. So to do this, let's find the first line of a custom rule. In this case, it's this attack-responses.ruules file. And I'm just going to hold the shift key and then arrow down to start highlighting all of these lines. And while still holding shift and the down arrow key, I'm going to go all the way to the bottom. Then with all of these lines selected, I'm going to let go of the shift key and then I'm going to press the escape key and the number three at the same time to add a pound sign or the comment symbol to the beginning of each line. And in this case, you can see that we've commented out all of these rules. And so now all we need to do is just press controll and x to escape. And then when we're prompted to save the modified buffer, we're just going to hit yes or the y key. And so now we can test our configuration changes. And as always, it's best practice that if we make any changes to a configuration file, well, we should test the changes to check if we've broken anything. And so to test our configuration file, we can just run pseudo snort with the capital T option to test and then the C argument to specify the location of our configuration file. In this case, it's under Etsy snort snort.com. And if we run this, we should get the test output. And we can see here that Snort successfully validated the configuration and there were no issues. If I scroll up here, we should be able to find the amount of rules that were detected. And you can see under initializing rule chains, well, currently we have zero snort rules read. This is because we commented out all of those rules, which is perfect. All right, so now that we're all set up here, let's take a very quick look at the three main modes that Snore offers. And if you recall those modes are the sniffer mode, so much like TCP dump or the packet logger mode where we can actually save packets to a file and also the IDS IPS mode which we're going to focus on in the later lessons. And so to run snort in the sniffer mode, we just need to run pseudo snort and then just simply provide the name of the interface much like TCP dump. In this case, ENP03 for myself. And now that it's running, well, we can make some network requests. So, in another tab here, I'm just going to curl google.com. And if I hop back over, well, we can see all of the packets that were logged. And we can see basically the packet header here. And so, I'll just cancel out of that. And so, to cancel out of this, I press C. And you might run into this bug where it just seems to be hanging after you tried to cancel it. In this case, I'm going to send over some more packets to google.com basically by curling the google.com URL again. And for some reason, doing that seems to stop whatever is hanging. And so this time I'm going to run snort again in packet sniffer mode. And in this case I'm going to provide the tac e argument to allow us to see the protocol headers like the IP or the TCP headers. And so if I run this again, I'm going to curl google.com once again and hop back over. Well, we can start to see things like the TCP header with the time to live, the type of service, even things like the sequence number and acknowledgement number and the window size. So, I'm going to cancel this out once again. And of course, it's hanging. I'm going to curl google.com, send some more packets over, and apparently everything's fine. The last mode here I'll show you is TACD. And much like with TCB dump, this is going to allow us to get the payload output in hex and ASI. And this time, I'll curl example.com with the HTTP protocol. And if we scroll up, we can see the actual packet. In this case, we have the response or the HTML response from the example.com website. If we scroll up to the first response packet, well, we can even see things like the HTTP headers. And for example, here is our actual request, our get request that we made with the curl utility as a user agent. All right. So that was much like when we passed the capital X argument to TCP dump. And in fact, we can actually provide this capital X argument to Snort itself. And this will dump the full packet details including the hex and ASI. So it's pretty much the same command. And so let's quickly cover the packet logger mode with Snort as well. And so once again, this is quite similar to TCP dump where we can capture packets using Snort and then output them to a file for later offline analysis. And so to use the packet logger mode, well, I'm just going to run the same command but provide the TAC L argument. And the default output folder here is going to be under var log snort. But we can also configure the default output directory in the snort.config file as well. Or in this case, we can specify a location within the command line itself. And in this case, I'm just going to hop over to the home directory and make a sample directory here called logs. And I'll just hop inside that directory. And this time I'm going to provide the tac l argument to snort and just provide a period to specify the current working directory. And so now that we're sniffing, I'm going to make another curl request. And in this case, we can't actually see the packets logged to the console because they're being logged to this file. And so I'm going to cancel out now. And again, I'm going to have to curl so we can quit properly. And then if I run an ls, well, we can see this snort log here with the Unix timestamp as part of the file name. And since we run snort with pseudo, well, this log file is also going to be owned by root. And so we can read in this file using snort just by running pseudo snort with the tac r flag. And in this case I will just provide the name of the log file. And if we scroll up we can start to see some of these packets. And there is also going to be a number of details at the bottom here. Similarly we can also run pseudo tcp dump with the same tac r flag and provide the same log file. And so you can see here that we can open up everything that we captured in Snort well into something like TCP dump or WireArk. And so this was a great start into the introduction and installation configuration and overview of the basic Snort features. And so in the next lesson, we're going to spend all our time with the IDS and IPS features and understanding and building out rules and catching some real attacks. In this lesson and the remaining Snort lessons, we're going to focus on its bread and butter, the IDS and IPS mode. And so with this mode, we're going to leverage predefined rules to process an action network traffic. And so to be able to write effective Snort rules, we first need to understand the generic rule syntax and its components. And fortunately, the structure in Snort version 2 is pretty straightforward. And so here's an example of a Snort rule. And snore rules are divided into two logical sections. On the left here we have the rule header and on the right we have the rule options. And so all of the text up to the first parenthesis there is the rule header. And the section enclosed within parenthesis is the rule options. And the rule header contains things like the rules action, the protocol, the source and destination IP addresses and ports as well. And the rule option section contains things like the alert message. So what's going to be logged when this alert is fired and also which parts of the packet should be inspected to determine if the rule action should take place. And we can get pretty granular here with the details or conditions that trigger the rule. We can do things like content matching or look at the packet size or specific flags within the protocol headers. And so to break down the components of this rule here, you can see we first have the word alert. And this is what is known as the rule action. And so this specifies the action to be taken when the rule is matched. In this case, alert means that well, an alert is going to be generated. But we also have different actions, right? We have log where we just log the traffic. And if we're running sore in that IPS mode, well, we can drop the packet which will block the packet from reaching its destination as well as log the traffic as well. And with reject, we can also terminate the packet session as well. So next we have the specific protocol and this obviously specifies the protocol that the rule applies to and in this case it's ICMP since we want to detect pings in this example. But we also have other options. So we can look at the IP protocol or TCP or UDP as well. Under the source IP we have any any and this basically means any IP address and any port. And so this rule is going to apply from any packets from any source IP address or any port. And since we're looking at ICMP traffic here, well obviously port numbers are not relevant. So that's why we just say any. In this case, we have the direction of travel. And so this indicates the actual direction of the packet's traffic. So in this case, it's specifying from source to destination because we have this arrow pointing to the right. And so we have two options for the direction here. we have from source to destination or this birectional data flow and obviously on the other side of this arrow here we have the destination IP address so 8.8.8.8 8 as well as the port. Now when we start looking into the rule options, we have things like message here and in this case this provides the message that will be included within the alert. And so in this case, we can put in a description of what the rule is detecting. We have an SID here and this is the snort ID and it's a unique identifier for the rule. And this is helpful for managing and referencing rules within the snort configuration. And so as best practice, we want to start our custom rules after the number 1 million. This is because that any SID lower than this is typically reserved for rules that are shipped by default with Snort. And as a general rule, SID should not overlap and should be unique for each rule. And lastly here, in the case of this rule, we have Rev 1, and this is the revision number. And this can be used to track changes to the rule over time, right? So if we make a change to this rule, for example, change the IP address here, well, we might want to increment the revision number as two so we can track changes accordingly. So we have more of a version control over our rule. And so to summarize, this rule is going to generate an alert for any MP traffic from any source to the IP address of 8.8.8.8. And I think once we start to break down the different components here, this rule becomes a lot more easy to digest. So now that we've defined our first rule, let's go ahead and add it to our rule configuration and test it out. And so to do this, let's head over to our local.rules file. If you remember, this is the default file within our Snort configuration that we can use to place our rules in. And so to alter this file, I'm going to run pseudo nano and then within the snort directory, I'm going to go under the rules folder and then into that local rules file. And you can see in this case this file is intentionally blank and does not come with any signatures. And we can put our local additions within this file. And so let's go ahead and put the rule that we just covered on this first line here. And so to follow along here, the action is going to be alert. The protocol is going to be ICMP. For the source IP address, we'll have any and port as well since it's ICMP traffic. For the direction, I'm going to use the dash and then the right arrow sign to specify it's going from source to destination. For the destination IP address, we'll just use 8.8.8.8, which is one of Google's DNS servers. For the port, of course, any as well. And now we get into the rule options. And so I'm going to put the parenthesis here and put the rule options inside this parenthesis. And in this case, we have that key value pair. And so for the key here, I'm going to have the message component or the message object and make sure to put a colon after each name. And I'm going to wrap the value here in quotes. And so for each option that we include, we have to finish it or end it off with a semicolon. So for the next option here, I'm going to specify the snort ID or the SID. And in this case, because it's not a string, we don't have to wrap it in these quotes here. Because for the SID, I'm just going to put 1 million1. And make sure to close that with a semicolon. And lastly here, I'll include the revision number with rev for rev. And again, this is not a string, so we can just put the number one. And make sure to close that off with another semicolon. And so in this case, our rule is looking pretty good. And so I'm going to save this by pressing Crl and X. and then save the modified buffer with the capital Y and then hit enter. And so I'll mention that in a typical deployment, Snort is going to run as a service which allows it to operate in the background and provide that real-time network intrusion detection and prevention. But since we're just learning and testing here, we're not going to configure that kind of deployment and rather we can start Snort manually from the command line to run and test it. And so when we run snort, the primary argument that we're going to need to remember and make note of is the capital A. And the capital A specifies the alert mode that we want to use. And so if I just run man snort here and scroll down a bit, we can see for capital A, we have alert mode. And we have different values that we can use. For example, full as the alert mode is going to provide all of the possible information about the alert. And this is also the default alert mode. If we use fast as the alert mode, well, this is going to show alerts in a more condensed format. And so it's going to show the alert message and timestamp, source and destination IP, and port numbers kind of in a more SIS log style. If we use none, well, we're not going to get any alerts. It's basically going to turn off alerting. And what's not mentioned here is we can also use console. And this is going to allow us to see alerts in that fast mode, but directly within our console when we run snort. And so I'm going to press Q to quit here. And let's go ahead and set up snort. So I'm going to provide tac a here. And in this case I'm going to use console because I want to see the alerts in the console as they appear. We can also use the tac l ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar ar argument to specify the log directory of where the alerts will be logged. In this case we can use the default of var log snort. And we also need to provide our interface for capture. In this case I will use03. And lastly, if you remember, we need to specify our configuration file with the C argument. In this case, it's under Etsy snort and then snort.com. And I will quickly sneak in the Q argument here to make sure that we run in quiet mode because if we don't, it's going to display an annoying banner and initialization information that we don't actually need in this instance. So once we run this, it's going to be pretty uneventful because we don't actually have any output yet. However, in a new tab, I'm going to test out our rule by pinging 8.8.8.8. Well, actually, first, let's try pinging a different IP address. For example, if I ping 8.8.4.4, well, you can see we're getting replies. But if I hop back over to our snort output, well, we still have nothing. So, what if I try pinging 8.8.8.8? And assuming we set up our rule correctly, well, we're going to get a match and get alerts for every ping. If I hop back over, well, we can start to see all of this traffic has been detected. And in this case, we're getting a timestamp of the alert. We're getting the SID or the SID of the alert as well. We're getting the message that we specified or the description. We're also seeing things like the traffic direction. So, we have the source IP address of our IP going to 8.8.8.8. And so you can see this fast option mode or in this case the console option mode is really useful for us to get a quick output. Okay, so let's do another example here. And first I'm going to quit snort. And if it's hanging up like this again, I'm just going to issue some more ping commands. It might just be my machine and the demo gods raining down on me. All right, so let's do another example here. This time let's work with the TCP protocol, which is a much more common protocol for these rules as the attack surface is much larger than say something like ICMP. And so I'm going to open up our local rules file again. And that's under rules, local.ruules. And so I'm going to delete our first rule here just by pressing control and K. And in this case, let's alert on any traffic that is going to a destination port of 4444. In this case, the IP addresses don't matter. We just want to monitor any outgoing quad 4 port traffic. And so to do this well, we want to specify an alert under the TCP protocol, any source IP address, and also any source port. For the direction, we want to specify any outgoing IP address going to port 444. For the options here, well, I just want to put a message of connection to remote IP on port 444. You can basically put whatever you want here. For the SID, I'm just going to increment our last one by one, even though we deleted it. And the revision number is going to be one as well. And so I'm going to save these changes. And so to test out that our rule is working, we can use the hping 3 command to send a specifically crafted packet over to example.com on port 4444. And so you can imagine that instead of example.com, well, this can be an attacker's controlled server listening for any incoming connections on that port. And if you don't have hping 3 installed, well, we can just run pseudoapp install hping 3. All right, perfect. So, I'm going to get our command ready. And so, I'm going to run pseudo hping 3. For the count, I'm just going to put one. We just need to make one request. Under port here, it's going to be 444. I'm going to put s just for a sin flag. And then specify example.com. All right. All right. And back over with Snort, I'm just going to run the exact same command. All right. So, now that we're listening and monitoring, I'm just going to run this hping 3 command to send a SIN flag over to port 444 on example.com. All right. We can see it was transmitted. And back over on Snort, you can see that we logged this one alert here. And just to showcase that it is working well, I can change this to basically any other port. And we're still not going to get any results. It's only going to be on quad 4 here. All right. So, I'm going to cancel that out and send another ping just so we can close it out. I don't know why that's not working. And so, this wasn't a particularly complex example, but for instance, the metas-ploit framework is a popular penetration testing tool, and the default Metas-ploit payloads will typically use port 444 by default when attempting to establish reverse shells on a target system. And also, various malware intro have historically used this port for command and control communications. And so you can see how we can start to monitor lowhanging fruit like this. And typically this type of thing will already be caught in the default and community rules, but I just wanted to show at the most basic level how we can create something similar. And so with this rule, we're basically trying to see from the perspective of the sock, what does the network activity look like and can we write any rules to log it or mitigate it and prevent it from occurring. And this is basically the essence of network security monitoring and network traffic analysis coming together. Before we move on to some more rule creation examples, let's briefly talk about community rules. And so community rules refer to all the rules that have been submitted by members of the open source community or the Snort integrators or developers. And these rules are freely available to use for all Snort users and are governed by the general public license. And so on snort.org here, we can go under downloads and then scroll down to the rules section here. And I'm not going to actually ingest all of these community rules, but just to show the general process, I'll make a quick directory to store them in, and then we can take a look at a couple. And so for version 2.9 here, I'm going to rightclick and copy the link to the community rules.tar.gz file. And so typically, we'd want to download and extract this file within the etsy snort rules folder. But for this quick example, I'll just make a sample directory and then run wget with pseudo and paste in that link so we can download it. If I run an ls, you can see that we downloaded this tar zip file. And so to extract it, I'll just run pseudo tar with the x, z, v, and f arguments and then provide the name of the file. And if I go into the community rules directory and run ls, well, we can see this community.ruules file, which we can then move over into our base directory. And if I just cut out this file to view it and pipe it over to less, well, we can start taking a look at some of these rules. And you can see that all of these rules are really well documented. So, we have things like reference URLs that we can return to. We have different things like class types and different metadata about the rule itself. And some of this metadata might include things like CVE numbers or MITER ids. And so if there was something in particular that we wanted to find or test, well, we could locate the rule within this file and understand how it's detected. You can see that a lot of these rules are looking at the actual content contained within the packets themselves. So you can see specific values in bytes or hex or different regular expressions as well. And these are specific patterns and signatures that can be found within the packets to alert on. And this is really how Snort's rulebased detection works in the sock. So next, let's take a look at logs specifically in the var/log/ snort directory. And you can see here we have files created from when we were doing testing. In this case, we have the alert fast file which includes all of the alerts from when we specified the fast alert mode. We also have the snore log files with these specific timestamps appended to the end of them. And these include the actual raw traffic or the captured pcaps from when a rule fired. And so specifically, let's find the most recent one here, which should refer to our quad 4 port rule. And what I can actually do here is just run pseudo wire and then paste in the name of this file. And you can see that wireark is going to open up here. And in this case, it's going to show us the captured packet. In this case, we had a single packet that fired off this rule. But we can see that the destination port here is quad 4. And so obviously this is not the best example, but you can see how absolutely useful this can be during investigations. If we can get an alert and then get the actual raw data and packets that were captured to fire off the alert, well, this incredibly expedites our analysis and response capabilities. And so I'm just going to remove all of the files within this directory. And then I'm going to run snort again, but this time I'm going to log some alerts. And so in order to log alerts, we can run snort again just like we did before. But in this case, I'm going to change the alert mode to either full or fast. And if you recall, full here is going to provide the full decoded header and the alert message. If I just run fast here, it's going to show the alert message and timestamp and source and destination in that SIS log style. And fast is the preferred method here if we want to actually log these alerts and then forward them to a SIM, for example, for correlation. And so I'm going to run this and then I'm going to head back over to our other tab here and I'm going to send a number of SIN flags over to example.com. And each time I do this, it should be triggering and generating an alert. And if I hop back over here, well, you can see we're not getting any output this time. But if I cancel this, and I'm going to need to send one more packet because Snort is being weird for me. And if I run an ls, well, we can see we have the captured raw packets. We also have this alert file that's been populated. And so if I cat out the alert file, well, we can see all of these alerts that were logged. And so once we're generating these alerts, well, we can have these logs dynamically forwarded into our SIM and create alerts on our dashboard. And this is what us as sock analysts will typically investigate and respond to when they come in. And because Snore is also capturing the raw pecaps themselves, well, we can then use what we learned from the network traffic analysis section to dive into these files and understand what happened and gather IoC's. So, you can really start to see how network traffic analysis and network security monitoring tie together, right? So, by setting up rules and capturing alerts, we can then forward them to our SIM. And so, lastly here, let's see Snort in action as an intrusion prevention system. So, so far we've been monitoring and alerting, but we can actually block or drop packets that match our rules as well. And so, to configure Snort as an IPS, we need to use the drop action within our rules instead of alert. And this will actively block the traffic that matches our rule. And so, to do this, I'm going to head back over to Etsy Snort and I'm going to run pseudo nano and locate our local rules file. And so, in this example, I'm going to kill this one here. Let's create a very simple rule that will drop FTP traffic after it's been detected on port 21. And also, let's get real here for a second. We don't have to be experts and memorize every single field and header when we're creating snort rules. And although the syntax is pretty consistent and easy to grasp, well, a tool like Snorpy here can be really useful for us when making complex rules. And Snorpy is a web-based snort rule creator which makes it very simple and easy for us to create custom Snort rules. And I'll include a link to the hosted instance of Snorpie here along with its GitHub repository because you can run and host this yourself. And so you can see how simple it is. It's just a very simple point-and-click GUI based tool that allows us to generate rules on the fly. And so under action here, remember we want to drop the packet. So I'm going to click on drop. Under the protocol here, we're dealing with FTP. So I'm going to choose TCP. Under the source IP address, well, we want to monitor any IP on our home network. So I'm going to put any for the source port. Remember this can be an ephemeral port as well. So we want to put any. But for the destination, we want to make sure the port is 21 and also any for the destination IP address because we want to monitor any external FTP communication. Under the snort ID, well I can just put 1 million and one again. And the revision number, I'll just put one as well. For the rule message, I'm just going to put a brief description of what we're doing here. And with that, our rule is ready to go. So, I'm going to click on this to copy it to the clipboard and head back over to our rules file. And I'm going to paste it in here. And when we do paste this in, it included a couple extra spaces. So, I'm going to make sure to remove those. And one quirk with Snorpy is that we weren't able to change the birectional flow of traffic. And in this case, I want to change the direction here from source to destination to birectional because I want to detect and drop any traffic flowing to or from an FTP server. And so we'll just save that. And so now that we've created a rule to drop traffic, we can now run Snort in inline mode. And again, typically within a production deployment where we're going to be running Snort as more of a service, we can actually configure this by default in the snort.com file rather than do it through the command line. And so to run it in inline mode, we can just run pseudo snort with the quiet option. Here I'm going to provide console for the alert output. I'm going to specify our interface here. So emp3 as well as our configuration file. And in this case, the capital Q argument here is going to tell Snort to run in inline mode. And inline mode is required for IPS functionality and is going to allow Snort to drop or modify packets in real time. And so if I run this, well, we're going to get an error message. And you can see here, pcap daq does not support inline. And this means that the data acquisition model that we're using by default or the libid pcap module does not support inline mode. And so to resolve this issue, we need to use a DAQ that supports inline mode like AF packet. Additionally, we need at least two network interfaces for Snort IPS to work as the AF packet module creates a bridge between them. And so the steps to do this are going to be dependent on your hypervisor. And you don't have to follow along if you don't want to, but I'm going to quickly set this up to demonstrate. And so in my case, I'm running Virtual Box. And so I'm going to rightclick and stop my machine here because it has to be powered off. And I'm going to open up the settings here and head down to the network settings. And in this case, I'm just going to go over to the adapter 2 tab and check off enable network adapter. And I'm going to go down to NAT network and make sure it's on the same one as my first adapter here. And so I'm going to press okay and restart my VM. Now I can run if config again. And in this case you can see I have an additional interface. So I have ENTP03 which is my default one but I also have ENTP08 now. So now I can run snort once again. And now what I need to modify here is the data acquisition unit that we're using. In this case, I'll do two dashes here with DAQ and specify the AF packet utility. And now for our interface, well, I actually need to bridge the two that I just set up. And so I will leave ENP0S3 here, but with a colon, I will bridge it over to ENTP0S8. And if you don't already have it, make sure to include the capital Q argument to run Snort in inline mode. If I just hit enter here, well, you can see we have nothing on the screen right away. But if I try to connect to a public FTP server, well, I can just run FTP test.rebex.net and try to connect to it. You can see that apparently we were connected, but now it's just hanging. It should be prompting me for username and password. If I head back over to Snort here, you can see we did get an alert. In this case, a drop action took place to drop the FTP traffic based on port 21. And if we hop back over, well, you can see the connection was terminated. And just to prove that this is working, I can press Ctrl + C here to cancel out Snort and try to connect normally. And in this case, we are being prompted for our username. And we can connect just fine. However, if I turn Snort back on, suddenly we can no longer connect and we are logging that drop packet. And so you can see by setting Snort to drop or reject traffic, well, we can actually prevent malicious connections and protect the network in real time. And so that was a lot of information and a very long video. And so feel free to review your notes or the rule syntax. And in the next video, we'll use what we learned to detect some real threats. So, I will see you in the next video. All right, and welcome back. And in this video, we're going to take a look at some more intrusion detection and prevention techniques within Snort and actually feed in some real malicious traffic and write custom detection rules to alert on them. And so, first here, I'm going to undo what I did in the last video. I'm just going to head over to the network settings here and uncheck adapter 2 because we're not going to need it for this lesson. And in this lesson, let's go through creating some custom detection rules for a variety of real malicious pcaps. And so to simulate us detecting traffic for our rules, we don't have to set up a lab environment and simulate live traffic. We can simply use Snort's option for reading in pre-established PCAP files. And as we read in these packet captures, we can leverage Snort's alerting and detection functionalities to evaluate our custom rules and make sure that we can catch the malicious traffic. And in this lab, we'll focus on detection rules since it's easier to showcase and we can pipe the alerts right into our console. And obviously, we won't be able to cover every single scenario here, but hopefully by covering some initial examples, you'll start to get a feel for writing simple rules which can be paired with the resources I'll include at the end of this section for further practice. And so, let's head over to the desktop and over to the network security folder. In this case, let's head to the snort directory and then under pcaps. And this is where we're going to find all of the example pcaps for this lesson. And so I'm going to open a terminal here. And in this case, to start off, let's open up 1.pcap in [Applause] Wireshark. And if you remember this pcap file, well maybe you don't just by first glance here, but this is the same one that we used to both learn TCP dump and wire sharkark. So this is the pcap from that system that was infected with Lokibot that made the HTTP request to download the malicious audiodg.exe Trojan. And if I just run HTTP contains audiod, we should be able to pull back that request. Yeah, there we go. Alternatively, I can go under statistics under HTTP under requests and we can also find the same audiodg.exe executable download. And so in this case, let's see if we can use this as an example to create a snort rule that can alert us on any.exe files that were downloaded over HTTP. And to do this, let's use the same Snorpie tool that I'll link down below. So let's set the action to alert. Under protocol, it's going to be TCP because we're dealing with HTTP traffic. For the source port and IP, well, this can basically be anything because we want to monitor our entire home network and any ephemeral port that these connections originate from. For the destination, well, we will have any once again an 80 for the port. Here, as best practice, I will put in an SID and a revision number. For the message, I will just include http URI contains.exe. exe. All right. So, at this stage, our rule is not going to match anything specific to executables, right? In this case, we're just going to match anything on port 80, which isn't ideal. So, this is where content matches come into play. So, I'm going to press the green plus button here to add a content match. And in this case, we need to choose what field we're matching the content off of. Because we want to match any.exe extensions within the URL, I'm going to click on the URI option here. I'm also going to click on no case here. And this is going to make sure the rule is case insensitive because attackers might try something like .exe with a capital X or two capital E's for example. And for the actual content to match, I'm just going to type in.exe. And to confirm this, I'm going to press the green check icon. And so we have our rule written here. And you can see that it automatically converted the dot here to this hex value of 2E, which refers to the dot. We didn't actually need to do this, but it's good practice. And you're going to see a lot of hex values within these content signatures. And so this rule in theory is going to alert when it detects any HTTP traffic where the URI contains the string.exe. And so if I copy this to our clipboard, we can close out Wireshark here. I'm going to edit our local rules file which is located in Etsy snort rules and then local.ru. And I'm going to delete our previous example here for FTP and paste in this new rule that we created. And I'll remove any white space as well. Great. So if I save this, we should be good now to run snort and test out our rule. So to do this, we can run pseudo snort and specify the name of our configuration file. We want to run in quiet mode as well. And in this case, we want to read in the pcap. In this case, it's going to be 1.pcap. And for the alert mode, we want to specify console so we get all of the alerts in our console output. So we don't have to go around digging for them. And if I run this, well, we get two results. So our rule matched two packets from this pcap file. And if I ls in the var log snort directory, well, we can see a number of alerts from our previous testing. In this case, I'm going to remove everything currently in varlog snort. And then I'm going to run snort once again and we should get these same two alerts. Now if I ls that log directory, we should get this snort.log file with our specified Unix timestamp. And from here we can dump or decode the packets that we matched. So I can run pseudo snort and read in that log file provide the quiet option and then tacd here to decode the packets. And we can see the raw packets as well as their ASI and hex output and start to understand how they matched. And if you remember from our initial analysis, we had this Bing API endpoint that made a request to that audiod.exe executable. And our second packet here is the actual download of audiodg.exe. All right. Nice. So we were able to create a custom rule to catch the request or download of any executable files based on the file extension. And so before we run the next example, I'm just going to once again clear out our varlog snort directory. Okay, so in our first example, we were able to detect the downloaded files due to the.exe extension included in the request URI. But what if the file extension is not included in the URI or it's obscured by other means? Well, we might need to rely on different detection methods to identify potentially malicious downloads. And one approach is to inspect the content type headers in the HTTP responses. So for example, many executable files are transmitted with the following content type of application XMS download. And we can use this string to trigger alerts. So I'm going to open up 1.pcap again in Wireshark. And if I find the same audgent type of application/x-m download and as mentioned earlier this mime type is commonly associated with the.exe file extension and is used by web servers to tell browsers and other client applications that the file being transmitted is a Windows executable so it can be handled correctly. So, let's create a snort rule that can detect HTTP responses containing the application XMS download mime type. So, I'm going to open up our local rules file again and make some changes to our initial rule. In this case, I'm going to remove all of our options here and I'm going to change the value of our message slightly. And if you think about the direction of travel here, in the initial example, we were looking at any destination IP addresses of port 80 because we were looking for when the client made a request to the web server. In this case, we're looking at a response header. So, we kind of want to reverse this, right? So, we want to put any for the destination port because that can be referring to a client's ephemeral port and from the source of the traffic, well, we want that to be the web server on port 80. So for the options here, we want to specify the content that we're matching. And we can do that with the content object. And within the quotes here, we want to paste in the string containing the exact header that we want to match. In this case, it's going to be content- type with the colon of application/x-ms download. And now we need to specify what field we're searching for to match this header. In this case, we can use the http header field. and make sure to end that with a semicolon. All right, so I'm going to save this rule here. And now we can try running snort again on the same 1.pcap file and see what happens. All right, so I'm going to hit enter here. And it looks like I might have messed something up. Ah, I forgot the semicolon after the message. So again, if you miss one of these semicolons, you're going to get a syntax error. And let me just make sure. Yep, I missed one here as well. Okay, so don't be like me and make sure you have all your semicolons. I think this looks good now. So if I run this again, but we can see we actually did manage to make an alert here. And in this case, the packet direction was from the web server going over to our client and stemming from port 80. And from here once again we can decode the raw packets that were [Applause] captured. Awesome. So we were able to create a second rule to match on a different part of the packet. So let's go through a third example here. And before we do this, I'm going to clear out the varlog snort directory once again. So for a third example, it's still possible for attackers to spoof the file extension and the content type header. And these are common techniques that attackers use to bypass checks or rules like these, especially in web server file uploads and in our case over network traffic. And so for this example, let's focus on detecting the file signature or the magic bytes of a Windows executable within the body or payload of an HTTP packet. Specifically, we want to identify that hex signature or that MZ marker which is indicative of the start of a Windows executable file. If you remember this Wikipedia article listing all the file signatures and magic bytes, if I do a search for MZ, well, we can see the actual hex value that makes up this file signature. We can also see the file types that it's associated with. For example, the ones that we saw are an executable file along with a Windows DL. And so to create a snort rule that can detect the MZ marker in the payload, we need to look for the hexadimal pattern of 4D 5A. And so to write this rule, well, we can base this basically off of our previous one. We can specify an alert for TCP packets on any destination IP with the port 80. Because remember in this case we're matching any responses from the web server. And so for the direction we're going to specify the destination of any any. And in the options here I'm just going to include a relevant description. And in this case we want to specify that we're matching file data. And this keyword is going to tell Snort to inspect the contents of the files transmitted over the network. Additionally, we want to specify the actual content that we're matching. And so within our string here, I'm going to specify that we're putting in hex values. And so to do this, I'm going to enclose everything within these pipe characters. And within these pipes, I'm going to paste in the 45A, which refers to MZ in hex. Lastly, here we can take advantage of the depth feature within our options. And when I type this, it's probably going to move over to the left. Okay, so hopefully you can still see that. And the depth option here is going to specify how far into the packet snort should look to match the specified content. In this case, we can just put two here to specify that we only want Snort to look in the first two bytes of the payload. In this case, matching the MZ in hex. And so we can really start to see the power of Snort here and its different pattern matching capabilities. And so as best practice here, I'm going to close this out with a SID and a revision of one. And so this looks good to me. So I'm going to save this. And to test out that our rule is going to work, well, I'm just going to run Snort once again on this 1.pcap file and see what happens. And you can see we did in fact get a hit. And if we open up the log file in Wireshark, we can see all of the relevant packets that stem from this capture. If I follow the TCP stream, well, we do in fact see the MZ file signature at the start of this file. Excellent. So that was three different ways and three different custom rules that we wrote to match a malicious file transfer over HTTP. And so before we move on here, I'm just going to clear out my varlog snort directory and let's take a look at the next example. And so for this example, let's open up the 2.pcap file within Wireshark. And if you recall, this is the pcap that we analyzed with TCP dump earlier that contained the cobalt strike activity. And during our analysis, well, we identified a malicious SS load DLL that was using a unique user agent string. To demonstrate this, we can search for the user [Applause] agent that contains SS load. And if I open up the packet here, we can see the user agent of SS load version 1.1. So this time, let's create a rule for this string that can detect an alert on this type of activity. And we already created some rules based on HTTP traffic before. So this should be quite simple. I'm going to open up our local rules file, comment our previous rule out, and start a new one here. This time I'm going to keep it very open and just alert anything under the content here. This is going to be the same process as matching the content type earlier. In this case, I'm going to paste in the user agent. And under the field that we're matching, I'm just going to specify HTTP header. And by using HTTP header here, Snort is going to inspect the traffic to determine if it is HTTP traffic regardless of the port that it's on. And so this allows us to catch HTTP traffic on any non-standard ports as well, which is sometimes common for attackers and command and control servers. I'm going to add the no case option as well, just in case we run across this user agent in a lowercase format. And then I'll just close it out with a SID and a revision number. So I'm good with that. I'm going to save and let's try running snort again this time under the 2.pcap file and see what happens. All right, so we detected a number of alerts here. In fact, we detected nine different alerts. And if I head back over to Wireshark and put in that same display filter of HTTP user agent contains SS load. Well, in this case, we also get nine packets, meaning that we successfully match the user agent via the headers. All right, before our last example here, I'm going to once again clear out our Snort log directory. And then for this example, let's move away from the HTTP protocol and look at SSH. And so 3.pcap here is a packet capture containing an SSH brute force. So I can open this up in Wireshark. And if we look at the statistics under the protocol hierarchy, well, we can see we have a large number of SSH traffic. And if we look at the capture file properties, well, all of this traffic was contained in 25 seconds, which is already suspicious of a brute force attack. But of course, like we've been doing, let's create a custom snort rule that can detect on potential SSH brute force attempts. And so, let's use Snorpy for this rule. Under action, I'm going to choose alert obviously and the protocol is going to be TCP. For the source here, I'm going to put any any. And the destination is going to be any destination IP with port 22 specifying SSH traffic. I'll put in a SID and a revision number as well as a rule message indicating a potential SSH brute force attack. When we go under the TCP options here, I'm going to click on direction and click on to server. And this can specify the actual flow direction that the rule will apply to. And so if we click to server here and under TCP state, I'm going to also select established. And this means that the rule is only going to trigger on traffic going to the server side of an established connection. And lastly here, we can choose the threshold tracking type. And you can see we have a number of different options to choose from. And the threshold option is going to generate an alert every single time our network traffic matches our threshold. So for example, if we set our count to five and our time period is 60 seconds, well, it will give us an alert on the fifth event and then the 10th event and so on as long as it's within that 60-second period. If we were to choose both here, well, this is only going to generate one alert within our set threshold period. For example, if we exceeded our threshold within that 60-second period, well, we're only going to get a single alert within that 60-second period. And so, to cut down on the number of duplicate alerts that we're generating, well, I'm going to select both here. And this is because we're going to set up some options that can detect if we've had more than five SSH connection attempts within 30 seconds. Under track by here, we can choose the actual field that we're tracking the threshold off of. So in this case I can choose by source to specify the source IP address of the connection. Under count here we can set a count of five. And under seconds well we can specify something like 30 for 30 seconds. And I also just realized I messed up the SID here. So I'm going to add a couple more zeros to make sure we're past that 1 million mark for best practice. And so how this rule is going to work is well snort is going to inspect the TCP SIN packets going towards port 22 or SSH. It's then going to track the number of connection attempts from a single source IP address. And if there are more than five connection attempts from the same source IP within 30 seconds, it's going to generate an alert. So, I'm going to copy this rule over to our terminal here and paste it into our local rule file. I'll comment out our previous one and paste this rule in. And now I'm just going to run snort on the 3.pcap file. and we should get some alerts from brute force attempts. And you can see because we set that 30- secondond period, we're only getting one alert. If I were to change this and actually edit the threshold instead of both here to threshold and run the same rule again, well, this time we're going to get an alert for every single attempt within that 30 secondond period. Or to put it another way, anytime a single source IP address exceeded five SSH connections within 30 seconds. And so this was a very simplified example. And in a real world scenario, you might want to fine-tune the threshold values like the count and the seconds based on your baseline traffic patterns so you can reduce false positives. And also there are built-in brute force detection methods like fail to ban. But I just wanted to showcase how it could be done with snort rules as well. And so that was a great exercise I think into various rules and methodologies around creating and tuning rules with Snort. And any other IDS or IPS system that you interact with like Siraata or Zeke is going to have very similar syntax and approaches. And if you want to dive into more complex rules and look into things like pre-processors, well definitely look into the community rules and the default rules that we looked at earlier. And you could learn a lot about thresholds and counts and various fields that you can define as well through these rules. And so now I think it's time that we use what we learned to go through a quick challenge and combine what we learned through PACAP analysis to then go ahead and create custom detection rules and improve our team's detection capabilities. And so with that, I will see you in the next video. Now that we've wrapped up the network security section, let's take a look at some additional resources that you can use to continue practicing network traffic analysis and custom rule writing for network security monitoring and prevention. And I will have all these links down below, but I'll quickly walk through some of them as well. And so the first one here is malwareanalysis.net. And this is a fantastic blog and resource by Brad of Unit 42 of Palo Alto Networks that focuses on well network traffic related to malware infections. And if we go to the archive here, it contains hundreds of realistic pecaps from actual malware infections in the wild. and it's an amazing resource if you want to continue practicing your network traffic analysis and detection engineering skills. I will list a disclaimer here to be careful with these samples because they do in fact contain real malware samples. So, as best practice, keep everything contained within your lab VM. And I fully credit this resource here for providing some of the pecaps that we use during the wire shark section because they really are just that good. Another great resource here is from Chris Sanders who is a master of packet analysis and an author of some fantastic books like practical packet analysis and applied network security monitoring. And he's also provided a list or a repository here of packet captures from over the years and you can download them here from GitHub within the Wireark wiki. Well, they also have a list of sample capture files as well. Additionally, this resource here from netresc has compiled a list of publicly available pcap files which is all freely available. We can also take a look at the zeke repository which is another type of network security monitoring tool as they also list some sample packet captures and traces as well. And these are the trace files that are used by the zeke test suite. And lastly here, Security Onion has compiled a list of public pcaps for their Security Onion test tool. And these are some that we already covered here, but also another great list of new resources as well. And so there's definitely no shortage of PECAP files for you to get your hands on and start dissecting and analyzing and creating detection rules for. And so I hope these lists are useful to you and that you were able to learn quite a bit about everything from the structure of packets to how computers talk to each other all the way to network traffic analysis and security monitoring. And so as a foreoding sentiment to the next section of this course, well, no matter how comprehensive our packet captures are and where our capture tools are positioned, they can't provide a complete picture of the actions and behaviors and modifications occurring on the endpoint alone. And so while they can reveal remotely issued commands that were not encrypted if an attacker utilizes encrypted protocols or encrypts its transmissions in some way while our pecaps become ineffective and also any changes on our actual system or workstation. So things like spawn processes or events and registry modifications all remain undetected. And so because of this it's often beneficial during investigations to pair our network analysis and endpoint security capabilities to get a full picture of what's going on at the endpoint level. And so with that, I will see you in the next domain of this course. All righty, everyone. Good job for getting through that network security section. I know that one can be quite long. Uh there's a lot of sort of stuff thrown at you, uh you know, all throughout the different tools that we touch on and cover. Uh but again, very important aspects for any sock analyst to know. Um and so with that, we are sort of going to move things over to the endpoint now, which is my favorite domain and my favorite section of the sock 101 course. Uh we're going to talk all about um not only how we can simulate malware, right? So we're actually going to be creating malware and uh simulating different attacks at the endpoint level, but of course we're going to learn uh and understand different techniques and methodologies and tools that we have uh to analyze those artifacts as they're being generated on the system in real time. And so I really think the endpoint security section really picks the course up uh sort of turns it up a notch and really uh deep dives into you know performing live incident response but also just learning all those different operating system and operating system level components as it relates to Windows and Linux uh and also working with an enterprisegrade EDR solution which I'm very excited to do. Um unfortunately we are going to have to cap off this section pretty early. Uh if you take a look at the time, we are getting close to the end here unfortunately, but I just wanted to sort of uh remind you all once again to check out the full uh sock 101 course on TCM uh to get, you know, your hands on all these different exciting domains. And so again, we'll have the link down in the description below for you to register uh and take the full course because uh if you made it this far, you're clearly enjoying it at least to some degree. So again, I highly encourage you to check out the full course and get all of those offerings. Welcome to the endpoint security section of this course. And in this section, we're going to expand the surface of our monitoring and analysis capabilities and well include endpoint devices as well. And so, as a sock analyst, understanding endpoint security is going to be an important focus for us because we're almost always going to be dealing with endpoints in incident response scenarios. And as we discussed back in the fishing analysis section, whether you agree with it or not, humans are often seen as the weakest link by attackers. and as such are often specifically targeted by attackers for their initial access or foothold into an organization. And we can think about endpoints as simply an extension of users. Right? So whether it be workstations in the form of desktops or laptops or mobile devices or even endpoints in the form of servers like web servers or database servers or FTP servers, all of these systems or endpoints need to be hardened and monitored as these are the targets that often serve as these entry points for attackers into the network. And by truly understanding the endpoint, we're going to be much more effective at identifying what's normal or abnormal on workstations and servers, or being able to correlate network traffic activities, or being able to map an attacker's tactics and techniques, and ultimately respond to incidents more effectively. And so, this section will provide you with the knowledge and hands-on skills needed to effectively monitor and analyze endpoint security events. And we're also going to cover endpoint events and logs in much more detail during the SIM or the security information and event management domain as well as the processes and methodologies for responding to incidents in the incident response section. And so there's going to be some natural overlap here, but understanding the fundamentals and components of operating systems and endpoints and how we can enhance their security is going to be very helpful before we dive into these topics. And so with that, let's jump into our domain objectives for this section. And so first we of course want to understand the fundamentals of endpoint security monitoring. And so we want to explore different things like endpoint types and controls and detection strategies. So we want to answer questions like what types of endpoints exist in our environment and what security controls can we implement at the host level and how do sock analysts detect malicious endpoint activity. And to do this we want to understand the core operating system components as well as their functions. And so we want to dive into what normal looks like in regards to processes and events and logs or network activity and the Windows registry. We want to develop practical skills in extracting insights from system internals. So we're going to actually take a look at the CIS internal suite and use it to analyze systems and extract valuable data and improve our endpoint logging capabilities. And all of our learning in this section is going to converge into a practical project to deploy and configure a unified endpoint detection solution. And so this section is going to be a lot of fun to cover and go through and it's really going to set us up for success during the rest of the course. And so with this introduction out of the way, I will see you in the next video. I suppose we should first define and answer the question of what even is an endpoint? And so in simple terms, an endpoint is any physical hardware or device that connects to our organization's network. And in the context of security operations, while endpoints are great tools that we can use for business productivity or communications or use them to stand up and configure servers, well, they can also serve as a potential point of entry for security threats. And endpoints can include a wide range of different devices. So, we might have various desktops or laptops that employees use for their day-to-day business operations, or maybe laptops that external stakeholders or third party contractors bring in and connect to our network. And workstations are common targets for attackers due to their widespread use and often direct access to sensitive information. So, we can think about attacks like fishing that often attempt to install malicious software or remote access Trojans onto an employes workstation. And so of course along with workstations there's been an increasing rise of mobile devices and tablets within the workplace. And these are additional endpoints that the sock also needs to track and secure within the organization as they can also be subject to fishing and malware attacks. And due to their portability they're also susceptible to physical threats like being lost or stolen which can lead to unauthorized access. And so we also have servers, right? And when we think of servers, well, these are endpoints that host various resources and business functions like applications or data or services that are essential to the organization's operation, right? So we might have internal or external email servers or web servers, database servers or file servers. And all of these additional endpoints require hardening measures and security controls to prevent things like breaches and data exfiltration and unauthorized access into the network. We also have things like IoT devices, right? So, these can include our smart devices like sensors and cameras and printers and any other appliance that's often overlooked as part of the organization's attack surface, but are becoming more and more common due to their smart features and ease of use within the workplace. And often, it can be hard to get long-term support for these devices, meaning that they can quickly lose access to security updates with no way of patching or remediating vulnerabilities. And while not IoT devices themselves, we can also think of some other categories of endpoints like OT or operational technology which are endpoints that are used to manage industrial operations or IC or industrial control systems and also SCADA equipment which all come with their own attack surface and hardening challenges. We also need to think about all of our networking appliances like routers and switches and firewalls that form the backbone of the organization's network infrastructure. And since these endpoints often run custom or proprietary operating systems, it can sometimes be difficult to install endpoint agents or monitor things effectively. But we will talk about this later on in the course. And so with this abundance of endpoints growing throughout an organization's environment, well, we need a way to implement security controls to monitor and alert on malicious activity or behavior occurring on the host or operating system level. And over the years, a lot of research and development has gone into evolving endpoint security monitoring capabilities. and vendors have invented many exciting acronyms to sell the latest and greatest hostbased security solutions. And so let's quickly go through the most prominent controls or solutions that you might see out there. And as we think about the concept of defense in depth, some of these capabilities pair handinand quite well together or have a lot of overlap with each other. And so the goal for an organization is to assess which controls align to their specific threat model and environment and prioritize their implementation based on that relevance along with available resources. And I'll also mention that the area of endpoint security can get messy in terms of, you know, where do you draw the line between what an EDR can do and a hostbased intrusion detection or prevention system, for example, or how EDR can integrate with UBA. Yeah, I told you there would be a lot of acronyms here. Or some vendors might have their own standalone products. So, it's always been very hard to compare specific vendor offerings between each other because they can all do different things and are always evolving to include more capabilities. Which is why I always like to say it's not ever about the specific tool or solution, but what the tool or solution aims to accomplish and what security controls it's aimed to enforce. And so first here we have anti virus or anti-malware. And this refers to software designed to detect, prevent, and remove malicious software or malware from computers and networks. An anti virus software typically works by scanning files and programs on your computer for various patterns or signatures that match known malware. And the traditional concept of antivirus has evolved into newer solutions, which we'll talk about soon, that move beyond the reliance of constant hard-coded signature updates. And these newer solutions can employ advanced detection methods like behavior analysis or huristics and machine learning algorithms to detect threats more effectively. Which kind of brings us into endpoint detection and response or EDR. And this is a technology focused on monitoring and responding to threats on endpoints in real time. And EDR solutions provide visibility into our different endpoint activities and can detect suspicious behavior and facilitate a more rapid incident response. And so EDR implementations will typically require the deployment of an agent on each endpoint. And this agent is what collects and transmits the telemetry data to a centralized EDR server or console where it can then be analyzed. And this agent monitors various aspects of the endpoint behavior. So things like process execution or file system changes or registry modifications and even network connections. And so while antivirus or anti-malware software focuses on preventing and removing known types of malware, EDR extends the capabilities to detect and respond to a broader range of security threats by analyzing the actions and behavior within endpoint devices themselves. And so this kind of brings us to XDR or extended detection and response. And to be honest, it's a bit of a marketing buzzword because it can mean a ton of different things. And so to generalize, XDR is really about the integration of multiple data points and other security solutions to have a more autonomous and quicker response to routine threats. And in some cases can even take automated action like blocking signins on compromised users or isolating endpoints from the network or forcing password changes or blocking web traffic or policy enforcement. And so XDR can expand the capabilities of an EDR and include other layers of operation like looking at the broader network traffic or email or cloud environments. We also have data loss prevention or DLP. And this is a strategy and set of technologies that aim to protect sensitive data from unauthorized access or use and transmission. Right? So DLP solutions can monitor and control data while it's in motion or at rest and even in use to prevent data breaches and ensure compliance with regulations. And so these solutions can detect sensitive data in different forms like text or files or images and emails all across different locations like endpoints and servers. And they can implement holistic access controls around sensitive data or do things like dynamic data masking on things like social security numbers or credit card numbers. And most of all monitoring the data transfer activities. So, for example, if an employee attempts to send an email containing credit card numbers or tries to upload sensitive financial reports to a personal cloud storage service, well, a data loss prevention solution can kick in and intervene based on predefined policies. We also have user and entity behavior analytics or UBA. Or you might see this as UEBA, which is slightly different, but we can generalize here. And this involves monitoring and analyzing user behavior patterns to detect anomalous or suspicious activities that can indicate things like insider threats or compromised accounts. And the big thing about UBA here is its ability to use machine learning and statistical analysis to identify deviations from normal behavior or a predefined baseline. And so it can build a profile and context on normal user behavior based on historical data and real-time observations. And so it can track things like a user or endpoint's typical login times or access patterns or how much data is typically transferred from that endpoint. And it can also consider the context around the user, right? So the user roles or access privileges or the actual geographic location that the user is accessing from. And so the goal of user and entity behavioral analytics is to identify potential insider threats or account compromises or data exfiltration attempts or just in general other malicious activities that traditional security controls might overlook. And this brings us to something we're more familiar with from the last section. In this case, we have hostbased intrusion detection systems or HIDs and hostbased intrusion prevention systems or HIPS. And these are security measures that of course focus on monitoring and protecting individual devices or the hosts from malicious activities, right? And so a HIDS is going to operate by monitoring and analyzing the internal activity on a host like the system logs and files and processes and configurations to detect any policy violations. And of course a HIPS on the other hand can take it a step further and automatically take actions like blocking network traffic or terminating malicious processes or modifying firewall rules based on these predefined rules. And there's going to be a lot of overlap here into things like EDR and XDR because typically these solutions can also take these automated actions and do things like quarantine devices or kill malicious processes or prevent specific file access. And lastly here we have a hostbased firewall. And a hostbased firewall is a type of firewall that operates of course at the individual host level to control incoming and outgoing traffic based on predetermined security rules. And so unlike network firewalls that typically protect an entire network by filtering traffic at the perimeter, hostbased firewalls are installed and configured on individual devices to provide more granular control over traffic flows and protect the host system from any unauthorized traffic or access. So we can further break down the main methodologies and components used to detect different types of host activities, focusing specifically on the key aspects that are targeted by these endpoint security tools. And we're going to use this to sort of guide us through this section as we explore how to monitor and analyze these activities on various operating systems. And so firstly here we have process execution. And this involves monitoring the running processes, right? So which processes are running on the endpoint any executable files and applications. And so we can analyze a list of running processes like executable files and applications along with their metadata, right? So things like their process ids or parent process or command line arguments that were passed along with the executable. And so we can use baselines to quickly determine and detect suspicious activity like a high number of processes being spawned or an unusually high CPU or memory drain from specific processes. Additionally, we can leverage reputation databases to evaluate the trustworthiness and reputation of processes based on factors like digital signatures or file origins or historical behavior or by analyzing the parent child relationships of processes. And so these refer to examining the hierarchical connections between various processes. So for example, is the winword process spawning command.exe or PowerShell.exe or other strange interconnections or dependencies of processes that aren't present in normal system activities. We can also look at file system changes, right? So we can track changes made to files and directories on the endpoint and detect things like unauthorized file access or the presence of known malicious files. And so we have things like file integrity monitoring that can monitor file systems for changes like creation or modification or deletion of files and directories. And this might involve maintaining a cryptographic hash or a check sum of files and comparing them against current values to detect any alterations or just analyzing file access behavior. Right? So if we have a rapid creation or modification of multiple files, well that might indicate a ransomware attack. Or if there are attempts to offiscate file properties like clearing out logs or events or altering metadata, well we can alert on that as well. We also have network connections and we're obviously very familiar with this from the last section, right? So we can monitor network traffic and connections going to and from the endpoint. And at the host level, well, we could take a look at what processes are making which network connections. We can see the associative files or executables. And this can all help us in detecting things like command and control communication by malware or remote access Trojan. And lastly here we have registry modifications. And so the Windows registry, for example, is a common target for attackers who want to establish persistence mechanisms or create back doors or evade detection by disabling antivirus or EDR software, for example. And so we can monitor these registries in real time and capture any modifications or creations of keys and values within the registry. And so with all of these common activity and detection methods, you can sort of start to see how much of understanding what is suspicious or abnormal on endpoints relies on having a great understanding of our baseline activities and what is normal. And that's the direction that I want to take this section. So, we're going to start looking at different ways that we can analyze various operating system components like processes and file activity or logs or the Windows registry, which is going to come in handy, of course, when we need to jump onto an endpoint in an incident response scenario. And so, let's start to get into all of this fun stuff. And so, I will see you in the next video. So, let's do something a bit fun here and create a very simple piece of malware to compromise our Windows VM from a simulated attacker on our Abuntu VM. And this is so we can have a live attack to showcase how we can investigate different endpoint components like network traffic and processes as they're occurring in real time. And obviously, we're not going to be creating malware and compromising ourselves within the sock. This is just so we can set up a very simple example to demonstrate the concepts covered in future lessons. And so to accomplish this, we're going to need to install and use the Metas-ploit framework. And Metas-ploit is a widely used penetration testing tool that provides a comprehensive platform for developing and testing and executing exploits against a variety of systems. And Metas-ploit includes a vast library of pre-built exploits and payloads that we can use. and it will specifically allow us to achieve a reverse shell and set up something similar to a command and control operation over our Windows system. And don't worry if some of this seems out of scope or confusing. Right? Your goal in sock 101 is not to learn how to compromise machines, but this is giving us a very simplified gist into what the attacker side might look like and with the added benefit of course of setting up our lab for this section. And if you're interested in the type of actions we perform in this lesson, well, definitely take the practical ethical hacking course if you haven't already. And so to install Metas-ploit, well, first make sure you're on your Auntu machine, right? And we're going to open up the Linux terminal here. And we're just going to follow the documentation on the Rapid 7 website, which I'll have linked down below. And within the documentation here, if we scroll down, we're going to see this section for installing the Metas-ploit framework on Linux. And specifically, we can copy this command here. And of course, we want to make sure what commands we're copying and running on our system. But in this case, you can see we're curling the repository, specifically an install file here, and then we're simply running the install file. And if we really wanted to, we could take a look at the actual script here, the installation script, and make sure we're not running anything malicious. And so what I'm going to do is copy this command, head over to my terminal, and I'm going to paste this in. And from here, it's going to kick off the installation. And of course, we're going to need our password here. And this might take a second to install as it needs to update a number of packages and install some dependencies. All right. And it looks like we're good to go. And so now we can simply just type in MSF console to start the tool. And you can see we're going to get a prompt here to ask us if we want to use and set up a new database. And so to do this, we can just type in y or yes to run the initial configuration script and create the initial database. And so again, this might take another second. Excellent. So once we see that MSF6 prompt there, we're good to go. And so now that we have the metas-ploit framework installed, we can use it to create an interpreter payload, which is a very highly versatile payload and handler that can provide us with an interactive shell using in-memory DL injection. And that's a lot of words and we don't need to understand what it's doing under the hood because we're going to start digging into that after we get our malware going. And so let's take a look at our VM networking because first we need to make sure that our Linux and Windows VM are on the same network. And this is dependent on the hypervisor you're using, but assuming you've placed them both within the same network. In my case, I can go under settings here in virtual box under network. And you can see I've attached them to this NAT network that I've titled TCM. And so next, since we're going to be creating a payload that executes on our Windows machine, we need to know where to tell it to connect back to, right? So in other words, what is our Ubuntu Linux's machine IP address? And so I'm going to press control shift and t to open up a new terminal tab here. And I'm just going to run if config on my ENP0S3 interface. I have the IP address of 192.168.1.4. So I'm going to make sure I write this down because I'm going to need it in a second. And so now that we know our IP address, we can create our payload. And Metas-ploit bundles with something called MSF Venom, which is a payload generation tool and utility that we're going to use to create our actual payload using a very simple syntax. And so again, I'm going to open up another terminal tab here. And in this case, I'm currently in my home/TCM directory. And for organization sake, I'm going to create a new directory here just called malware. And I'm going to CD into that directory because this is where I'm going to drop the payload that we generate. And so to run MSF Venom, I'm just going to type in MSF Venom. And from here, I'm going to provide the P option. And this is going to specify the type of payload that we want to use. And in this case, there's a syntax that we want to follow for this. Since we're going to be executing our payload on a Windows system, well, I'm going to type in Windows here. And after Windows, I'm going to put a slash here. And now we can specify the type of handler that we want. In this case, it's going to be that interpreter handler. And lastly, I'm going to put another slash here. Then I'm going to provide the type of payload. In this case, we want to create a reverse TCP connection or that reverse shell from the target machine back to our attacker's machine. So, I can just type in reverse_TCP. And so, this means that when the payload is executed on the target system or our Windows system, it will initiate a connection back to our specified host, allowing us to gain access and control over the target machine. And so, we're not done yet. There are a couple other options that we want to include. We need to specify the listening host. In our case, it's going to be our Linux machine's IP address or our attacker machine. And I'll do that with the LHOST option and set that to 192.168.1.4. And so remember, your IP address might be different. That's why we did that check first with if config. Next, we have the Lport option, and this specifies the listening port in which we'll receive the connection from. In this case, I'm just going to choose the default of quad 4. under F here. This is where we can choose the file output of our payload or the file type that we want the payload to be. In this case, I want it to be an executable since we're running it on a Windows system. So, I'm going to type in .exe. And then lastly, we have the O option. And this provides our output file. And in this case, I'm just going to call our malware notmalware.exe. And with all this ready, we should be good to go. So, I'm just going to hit enter here. And it might take a second to generate. There we go. We can see that the file was saved as notmalware.exe. And if I run an ls here, we can see our file. And if I run a file command on notmalware.exe, we can see that it's a PE32 executable. And interestingly, when we create this payload, it's going to create itself as a known good or trusted binary by default. And it actually impersonates the Apache benchmark utility or ab.exe. exe. And this is going to come into play later when we start looking into the process of the executable itself. And we might wonder why our malware is being classified as Apache benchmark. But this is all done so that we can create somewhat of a Trojan horse. Whereas when an investigator or different scanning utilities look this over, they're going to see what looks like to be a benign Apache benchmark utility. And so now we can set up our interpreter listener to catch the eventual shell that comes back to us. And so over in our first tab here where we have metas-ploit open and if you did happen to close it, you can just run MSF console again, we can now set up and execute our listener. And so to do this, we're going to type in the use command here. And we're going to select the type of handler we want to use. In this case, it's going to be exploit. And I can just tab there to autocomplete. I'm going to type in multi and then another slash for handler. And so I'm just going to run that. And you can see that the handler was configured. So next we want to set the payload. And so again, we want to match the same payload that we used when we generated our malware. And so to do this, I'm going to write set payload. And I'm going to set that to again Windows/terprepter/reverse_tcp. And again, you can autocomplete that as well with tab. All right, we're almost there. We need to set our LHOST again to either again our IP address or we can use our interface. Right? So I can type in ENP03 and it will automatically convert that to whatever my current IP address is. And lastly, we want to set our listening port with Lport to quad 4. We actually don't need to do this because this is the default port that my interpreter will listen from, but obviously it's good practice to manually set this. And so now that we're ready to go, we can just type in literally exploit and this is going to run our listener. We're not going to connect to our machine yet, right? We didn't even get the malware over there, but it's going to run our listener and payload handler. And you can see that we've started a reverse TCP handler on our IP address on port 4444. And with that, we are ready to catch our shell. And so now that we have our payload created and we're listening for the connection, we can transfer it over to our Windows machine. And so on Ubuntu, let's host this payload using the Python HTTP server so that it can be publicly accessed and downloaded from our Windows client. Again, we're sort of taking a peak behind the curtain here so we can compromise ourselves easily. In theory, we could think of an attacker sending this over as a fishing email that contains our payload as an attachment or downloaded from a link. And so to do this, make sure you're in the same directory that we created our malware in. And then I'm going to run Python 3 with the M option here for http.server. And I'm going to select the port of 8000 to listen on and host our server. And so now we're ready. We're serving HTTP on port 8000. And so from here, I've started up my Windows machine as well. Right? So I have both machines running. I have my Linux machine and my Windows machine or our victim in this case. And so now on Windows, we can open up Edge or you know, Internet Explorer, whatever you want to use. I'm going to paste in HTTP the IP address of my Linux machine and then with a colon here, specify port 8000. And if we open that, you can see we get the directory listing. And this is our Python HTTP server in action. And so this is going to list all of the files in the directory that we're serving from. And of course, we can see notmalware.exe. And if we click on this, it's going to download to our local system. And we can see in the top right here that this is not a commonly downloaded file. And so Microsoft is trying to warn us here to be cautious around downloading this file. But what we can do is just click on the three dots here for more actions. And then we can go over to keep because we want to keep this file. And again, we're going to get another warning from Smart Screen here. So, Microsoft really doesn't want us to download this file. And so, you can see all of the built-in protections that are seeing our payload as suspicious. And realistically, an attacker would put more work into obiscation and methods to get around simple detection like this. And, you know, obviously, we didn't create any advanced malware or anything. And this would definitely get picked up by most antivirus solutions. And so, this is not an AV evasion course by any means. And so, I'm going to click on show more here. and I'm going to click on keep anyway. So, we're basically saying, "Please let us keep this malware." All right. So, now that we finally downloaded the malware, let's open up a command prompt as administrator. And so, we're going to simulate an administrator user falling victim to this malware, giving our attacker full compromise over the system. Or we could assume that the attacker was able to gain an initial user shell and then from that foothold escalate privileges as administrator. And so, I'm going to click on the start menu here and then type in cmd. And then on the command prompt application here, I'm going to rightclick and then select run as administrator and just say yes to the UAC here. And we now have a command prompt running as administrator. All right. So I'm going to head over to the C directory over to users and then the user I configured for this machine is called TCM. And then I'm going to go to my users downloads directory. And if I run a dur here, well, we can see notmalware.exe. And so all I'm going to do is just type in notmalware.exe. And then I'm going to hit enter to run that. And as soon as I do, I'm going to hop back over to Abuntu. All right, I'm going to go back to our metas-ploit shell here. And you can see that we did open up a interpreter session. And specifically, we can see that it was opened up on our listening port over to the attackers machine. This is our Windows IP address on this ephemeral port here. And so we successfully caught a reverse shell. And so this is going to be the general process for setting up the following lessons. Right? So we're going to want to keep this active reverse shell connection so we can look into network and process activities on our Windows host. And if for any reason you need to, you know, close out everything and restart it, well, just follow these steps once again. Make sure to set up, you know, we've already transferred the payload over, so you don't need to do that again. You just need to set up metas-ploit here. set the payload and options and then just simply execute the program on Windows. And so now that we've compromised ourselves, I will see you in the next lesson. Again, a big thank you to Flare Academy for sponsoring our 12 hours of sock 101. Cyber threats are evolving fast. And staying ahead is not just an advantage, it's a necessity. And that's where Flare Academy comes in. Flare Academy is an educational hub designed to democratize cyber security knowledge. Backed by the Flair research team and leading threat intelligence experts, they provide accessible training, collaborative discussions, and cutting edge resources. With the support of Flair's industry-leading research team, members gain access to hands-on insights and training while connecting with peers and experts to tackle the toughest and newest challenges together. This is through practical sessions designed to solve real world cyber security challenges. The opportunity to engage with industry leaders, researchers, and fellow professionals to grow your skills, community meetups to share insights and experiences in both virtual and in-person events, and exclusive research and tools such as access to cutting edge reports, tooling, and intelligence from Flair's experts tailored specifically for the community. With Flare, you can learn and grow through in-depth training sessions on credential management, reconnaissance techniques, OSENT, and much more. Delivered by industry leaders like Jason Hadex, and backed by Flair's research team. You'll get exclusive access to expertly crafted solutions, playbooks, and session materials designed to address real world cyber security challenges. You'll be able to participate in expert-led discussions and Q&A channels and stay ahead of emerging threats with exclusive reports, feeds, and insights from Flair's comprehensive cyber crime intelligence. And verified members gain access to premium resources and private insights while contributing to a community that thrives on shared knowledge. And so, if you're ready to level up, join Flare Academy today through the link in the description. All righty, my friends. Sadly, we are going to need to cap things off for now, but I really hope you enjoyed everything we covered up to this point. You know, we really only did scratch the surface of the full sock 101 curriculum. And I'm kind of leaving you on a bit of a cliffhanger here because the endpoint security section is really where things start to pick up in the course and really where we start to correlate some of the different things we're seeing on the network side. Uh, and also how we can hunt malware and different persistence techniques uh and even perform a bit of sort of live incident response on the endpoint level. um and even working with an EDR as well. And then of course, as we talked about earlier, we start talking about the SIM and we start working with Splunk uh and how we can ingest logs and work with logs and sort of cut them up as well uh manually and also using tools like a SIM. And of course, we get into threat intelligence and how we can collect and ingest and use uh sort of the the intelligence we're ingesting uh in order to make better uh decisions as an analyst. And of course we have this whole digital forensic section where we really deep dive into different forensic artifacts on the endpoint uh and also how we can triage and work with uh many industry standard forensic tools as well and we really roll that up into incident response as well. So just like we talked about at the beginning of the video, we really are only scratching the surface here. So, um, if you did enjoy everything we learned up to this point and you want to sort of continue on further, I really encourage you to check out the TCM Academy uh, and get a academy subscription where you can check out both the sock 101 and a ton of other courses that we offer on the academy both in defensive and offensive security as well and even programming. And so, with all of that, I want to thank you yourself for getting up to this point, right? Uh, that was a ton of knowledge dropped on you in a condensed 12-h hour period like that. So, uh, that's not easy, right? So kudos to you. Uh I hope you took good notes. If anything is unclear, you can always go back on the chapter sections there and revisit certain areas. And of course, again, if you did enjoy uh the course and want to continue and expand your knowledge, feel free to check out the full course at the TCM Security Academy. And so, please feel free to leave a like on the video and subscribe to the channel if you haven't already because this is not the first time we've dropped one of our courses like this on the uh TCM YouTube channel, right? So, I love that we get to do this every now and then. Uh and so with that, thank you again for watching and I will catch you next time.