Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"


0 (0 Likes / 0 Dislikes)
Hello. Thank you for joining us. We're going to discuss tactics to uncover active attacks during today's webcast Threat Hunting 101. We will talk about the difference between targeted and opportunistic attacks and the steps that adversaries to take to achieve their objective with a live demonstration of threat hunting in action. I am Casey Cross and I work in product marketing at Palo Alto Networks focusing on detection and response. Hi, I'm Mike Gotham. I'm a systems engineer here at Palo Alto Networks with a background as a threat hunter and I specialize in network and endpoint forensics as well as malware reverse engineering. So Mike, with your experience in threat hunting, can you tell us what it is and why it's so important? Yeah, absolutely. So threat hunting is essentially actively looking for your environment for known and unknown threats. So this may be things that you've seen before, like known bad IP addresses or domains. It could be looking at suspicious behavior, but it's essentially looking for some of those outliers that you may not have seen through your alerts or incidents. Maybe that's new tactics an attacker has, but that's why threat hunting is really so beneficial to us as security practitioners and why it's so necessary. Yes, Mike, that's true. In fact, there was a recent survey that found that for 37% of organizations, over half of all investigations started with threat hunting. So if organizations don't have an effective way to find threats through threat hunting, they probably will leave attacks unnoticed. What are some examples of attacks that you found through threat hunting? Yeah, that's a great question. Casey. Some of the things I've seen during threat hunting are creative things that an attacker has done, so maybe they've called into the help desk and impersonated a user to get access, which is, you know, very hard to track with threat hunting. However, you could look at some of the things that particular user did, somebody that's in human resources in an organization is now doing tasks the administrator would normally see. That was one thing that we found that would be interesting, because you'd see somebody that doesn't have a background in that particular area, but they're running commands that you would expect somebody with a detailed background in IT administration within your organization. And large organizations see a lot of different things that could range from, commodity malware being put on boxes, web shells is very popular, we see a lot of those. And then there's been other creative techniques like living off the land, using tools like PsExec or some of the tools that organizations are leveraging and expect to see to actually accomplish whatever that end goal might be. Whether that's to steal intellectual property, sensitive documents or maybe even other motives like political or whatever actually drives this particular attacker. Yes, Mike, that's true. And later on in this webinar, I think we'll demonstrate living off the land as well as web shells and how you would detect them. So there are some attacks that are more dangerous than others. Can you tell us a little bit about each type? Yeah, absolutely. I put attacks into two broad categories. So the first is opportunistic attacks. These attacks aren't the ones that keep me up at night. These would be things like a commodity-based malware, or you may have heard them called spray and pray-type attacks. This is where someone will blast out an email to whoever will click on it. Hopefully now those machines can be used in another campaign like distributed denial of service, installing Bitcoin miners, which has become pretty popular over the last couple of years. But although there's inherent risk there, that's not really the very scary stuff. Target attacks is the other big category and those are the ones that really scare me. The reason why they do is typically the attackers behind those are little bit more sophisticated or can be a good bit more sophisticated. They're very methodical in what they do and they have a set of objectives they're trying to act on. So in a targeted attack, they're coming into your organization looking for something or trying to do something. And those are the ones that really concern me as a threat hunter and security practitioner. That's true. So what are some of the things that you look for when you're threat hunting? So it can be a number of different things. Really, I just always look for a string to pull on and maybe that could start out with an IP address or a domain or registry key, mutex, maybe that's someone else coming to you and saying, hey, as a partner we saw this suspicious communication. Sometimes that can even be a particular behavior that may be abnormal. One of the cool things about Cortex is, we have this concept of behavioral indicators are compromised, which actually look for combinations of events that may bubble up, if things are interesting. But once you find something that you can actually latch onto, you go from there. So maybe after you find an IP address, you look at all the other machines that talk to you. Then you looked at all the user IDs that are associated with that, and so on and so forth until you've got this big whiteboard, spidering out that structured detail of the actual campaign or attack itself. And I think we're going to show you some of those techniques now as we show you how to threat hunt with an attack simulation and threat hunting demonstration. In our attack and threat hunting simulation, I will be the attacker and Mike will be the threat hunter. And so we'll show you an attack based on actual techniques that we have seen. And my attack plan consists of the following steps. First, I will use compromised credentials that I found on the web to get access to the network through a VPN tunnel. Then I will steal credentials from the machine that I've landed on and I will move laterally and maintain persistence. And then I will exfiltrate data and then hide evidence that I was ever there. So since I'm ready to seal some data, let's start this attack. So I have been targeting a specific healthcare company for months. I've tried all of my standard techniques like malware, legitimate credentials, social engineering and wheat credentials. Fortunately for me, an employee in the company used their corporate credentials on another website and that website was breached. And so I was able to obtain working username and password and I was able to access the network through a VPN tunnel. And once in I was able to access an endpoint. From there I was able to steal credentials from the endpoint. So now that I've gotten into the network I need to escalate privileges. So I basically need to find an IT administrator account. And so I'm going to scrape the memory of the host that I'm on and see if I can find any interesting credentials. And luckily, because the machine that I'm on is an older operating system the memory should contain the username and password in clear text. So first I try to invoke Mimikatz with PowerShell and I do that in order to evade detection because some antivirus agents are going to detect Mimikatz as an attack tool. And then when that doesn't work, I decided that I'm going to take my attack offline, so what I'm going to do is just dump all running memory and then I'm going to transfer that memory to my machine in my network, away from the attack network and then I'm going to analyze it and find the credentials I'm looking for. So what we're going to do now is hunt for some credentials scraping or potentially this attacker trying to escalate privileges. What you're looking at right now is the main Cortex XCR dashboard. This'll give you a summary of any incidents that are out there, information about hosts, some of the criticality and then trending. Where we're going to want to focus our time is actually building queries. As a hunter querying for data that may not have already bubbled up as an incident can be very valuable. I'm going to go ahead and go in to my query builder here and I've got some prepopulated queries that we're going to run. But just to give you an idea of some of the queries that we can run, you can look at file events and so reads, writes, deletes, creates, renames, we can look at process events, processes being executed, remote threads being spun up, network events, so how much data left and came in as well as the address port host name. You can search across of event logs in windows. So if you have a particular windows event ID that you'd like to pull, you can do that as well and then registry events. Now if you wanted to use multiple sets of these fields, you can leverage the all actions field and start to combine those together. So we're going to go ahead and go into my saved queries here under query center. And the first one we're going to look at is for different invoke arguments. Now what we're looking for specifically here is PowerShell invoking Mimikatz. I have a pretty broad search query here, although you could certainly tighten this up by using certain binaries, including users, including machines in scope and that would dramatically help to narrow your search results. I'm going to go ahead and go show results. I've got that open here in another tab and you're going to notice I have a breakdown of the data that I've seen before. So what I was looking for here was this invoke expression and you can see here, if you look at my right hand side where the entire command has come up, you can see that this particular user is leveraging PowerShell to download the invoke Mimikatz PowerShell script, put that into a string and actually run that. Now if we look here, we've got a couple of different icons, suspicious process creation, PowerShell running a download command from the command line, which by the way, you'll see normally within your environment that that is somewhat normal behavior and that's why you'll see these gray icons. That means the severity was informational when you saw these. And then the alerts bubble up into something called behavioral indicators of compromise or BIOC’s and that's essentially looking for combinations of logic and behavior to help point you in the right direction. As hunters, these are great to know and these are great to modify to get additional data that we may not have seen with just the general query itself. You'll also notice that there's a medium severity event, It's here in yellow. So now that we've seen this attacker is trying to grab credentials, we want to check to make sure, one were they successful, which we could look at potentially windows logs, we could look at some of our other tools that we have on the endpoint like traps. But specifically we're going to make the assumption that the tools we had like antivirus successfully blocked PowerShell invoking MimiKatz, so we're going to take a little bit different approach now. I'm going to go back in here and run a query that's looking for proc dump, dumping the memory for Alsace. Now Alsace for anybody that's not familiar, controls Windows local authentication and on machines, especially Windows 7, Windows Server 2012, older versions of Windows, those credentials were in memory-cleared text. What an attacker might be doing here is, if they can't leverage their tools on the box, dumping the process memory and moving it offline. We're going to run this query as well and go ahead and show results which I already have populated in a new tab. If we look here, we'll see there's a little bit different red alerts but we've got that same type of information around the description of the actual event and then you'll notice again here we have several alert names. These were some of the BIOC’s that actually flag. But what I actually want to look for here is this command. So I see procdump.exe. I actually ran and tried to dump process memory into Alsace. Now in this particular instance, Traps detected that as a behavioral threat, because of a chain of actions. So we can look at the Traps logs to see if that actually was blocked or if that was just an alert there. Now what we're going to do, since we've identified that the attacker is looking for credentials, we're going to start looking for other types of characteristics like lateral movements, setting up reverse shells and other type of suspicious behavior. So I was able to scrape credentials from the initial endpoint and now I'm going to use those stolen credentials to move laterally to an active directory server. So I'm going to start by using PsExec, which is a Microsoft tool, which will allow me to log into the active directory server and perform commands. And then my next step will be to move putty, which is an SSH client to the active directory server. And then I'm going to create an account on my command and control server and then I will establish a reverse shell connection out to the command and control server. And the reason for that is then I have basically a persistent connection to the active directory server from my command and control server. So my first step once I've logged into the active directory server is to download an SSH client, so I will download it, I'll move it to the active directory server, I will rename it so that it doesn't raise suspicion and then at that point I can establish my reverse shell connection out back to my command and control server. Now what we're going to start looking for is any sort of lateral movement and potentially incoming trenchment like reverse shells. I've already set up a query here and this one also is pretty general. What I'm looking for here is any kind of arguments, that says putty. You could also look at remote… other remote access tools, as well as other tools like log me in, WebEx or other sharing and collaboration tools. I'm going to go ahead and run this query and show the results, we've got that pulled up on another tap over here now. So similar to the other screens we've seen so far, we've got a ton of detailed information including the action type. You'll notice there's a mix of network events as well as process events and then anything that matched the BIOC also goes ahead and maps out what part of the kill chain it is associated with. You can also see that up here on the left hand side, as well as the network events that highlight there was some upload and download as well as some outgoing connections. So if I read this from the bottom up, what I'm looking at here is command.exe was started and then it looks like some commands were leveraged. So this is a net use command mounting a share to our domain controller here mounting to the root. If I look, I can see the connection from one box to the other as well as the amount of content that went over the wire, which can be very helpful, especially when you start to look for things like data exfiltration. You can actually see and compare the file sizes that you believe archives are packaged up and that particular attacker is trying to exfiltrate. You can get an idea of whether that left the organization in full. Now, what you'll notice after that is this particular attacker is pinging the domain controller and you'll see those commands over and over. Now, attackers just like anyone else are human beings, they'll make mistakes, they'll make typos, they try and automate as much as they can. But sometimes you have to actually just enter in commands and this can give you a lot of insight into what the attacker's trying to do and if you understand what their objectives are, that can help you for your next step of investigation as well as potentially your remediation plan to kick out the attacker. If I move further up, I see a process event where PS exec was run and my command, once I've highlighted over was to actually add a registry key. If you look that particular registry key is adding a certificate as a trusted host on this particular machine. Now if I continue to go up, I see some more networking events, as well as now I see a file named SSH.bat.exe, which is actually my renamed version of putty when that was moved over to that particular share. And you can see this particular attacker is using PS exec to start putty and potentially set up a remote shell and a remote listener there. Now what we're going to look at is if there's any kind of persistence mechanism to actually go in and start that up, every single time this box launches. A domain controller won't be reset many times, however it does happen. So the attacker wants to make sure when it does, their instance of putty launches yet again. Okay, so now my next step is I want to have persistent access to the active directory server through the reverse shell. So my next app is a scheduled task on the active directory server and this makes sure that the reverse shell is always on. And I can always access the active directory server whenever I want to. And then once I've done that, so through my reconnaissance I've been able to access some critical and valuable information including AWS keys, including healthcare records. And so I want to package all of these files up into larger archives and then move them to a staging area, where I can transfer them out of the network. And the reason for this is that I believe it'll be easier for me, as well as less noticeable if I upload a couple of files versus thousands of files. So my first step is to use 7-Zip to create an archive and then I move it to the staging area. Now we want to try and look for persistence mechanisms. So we believe an attacker may have moved putty over to our domain controller. Maybe what you want to do, additional inspection specifically, did they set up any scheduled tasks to make sure the listener continues to listen the next time that domain controller is rebooted. Reboot on a domain controller doesn't happen often, but it does happen. The attacker wants to make sure they have a way to get back in. Going to go ahead and show the results of this query, which is essentially looking for anything that references scheduled tasks that exe in the actual command line itself. After getting the results of that query, I'll notice a command that exe ran some commands with PS exec and these are pretty straightforward. We see PS exec was used to run command remotely on the domain controller. That command ran scheduled tasks that exe and created a scheduled tasks that essentially ran and runs our listener. You could see in the previous example, ssh.bat.exe we identified as a renamed version of putty. Again, you can confirm that using the MD5 from that file, either from Cortex XDR, from the box directly or any other tool you may be able to use to retrieve this file. We also see some network communication here and this is actually moving across the wire from the initial victim machine over to our domain controller. Now that we've seen a scheduled task has been set up, we want to look for any files that may have been packaged. Again, we'll click show results and will be brought to a detailed view. Again, in the commands that were actually listed there. Here we see a file referenced called hotfix.deb with command line arguments that look like they're associated with 7-Zip. My query that I originally leveraged to get here, was looking for anything in the command line that noted 7-Zip. If I scroll over, I can see that my seven zip actually compressed everything that was in the user's shelled in documents folder on that individual's machine, where the landing actually occurred. Now one thing that would be very interesting to me, is to understand exactly what was in that archive. If that archive has left my organization and contains sensitive data, it might require the immediate need to declare a breach. However, if the data within that archive wasn't sensitive, we may be able to keep moving forward towards investigation and a remediation plan to kick this attacker out of our environment without having to declare a breach. To pull this file I'm going to use Cortex XDR’s live terminal feature. You could grab this file using Windows tools or if you have another software, piece of software in house that has the ability to remotely grab files or issue commands, you could leverage that as well. So I'm going to go ahead to my live terminal, enter the machine name, which is Microsoft RMS client, W10, now I'm going to click my connect button. Now that my live terminal has been opened, I have a lot of different ways I can interact with this box. The first place I'm dropped into is Task Manager, which will show me all the processes that are running on the box as well as the context that they're running as, any command line arguments, as well as memory and CPU cycles that these are taking out. I'm not as concerned about what's running on the box at the moment, but more of what was in those files. If I click my file explorer view, we drop down, the only drive here is C, going to go in to C, users, shelled in, documents. Remember, this is because that was referenced during those command line arguments that we showed you just a minute ago, before we came into the live terminal. In here I noticed that there are certainly some sensitive files that I would want to take a look at and be wary of and make sure I can get a copy of that archive. I see references to AWS private keys, PCP private keys, network topologies and long term cloud strategy plans. Now I want to go ahead and try and confirm that that's what was actually in the archive. I know that this particular actor through the command line arguments I saw, dropped this into Windows 10, which seems to be their preferred staging area on this local machine. Now you can see I'm in Windows 10 and there's a couple of things as a hunter that might be outliers for me or maybe items of interest. So the first is, I can pull my documents dot seven zip file, which is great. I'll go ahead and download that, so we can inspect that here in a couple of minutes. However, there are some other things that are of interest, that stand out very quickly to me when I come into this temp directory and I start to triage. The first thing you'll notice is the file owner names here are typically administrators or systems for Windows and things in the temp folder for Windows. However, I can see that I've had file owners that are not those particular user names in here, in particular two files right here, one called the HP laser jet printer driver. Printer drivers can sometimes be a great place for actors to try and conceal themselves. Printer drivers can be very difficult to do reverse engineering on or malware analysis and reverse engineering, so a lot of times they'll get overlooked or at a first pass be glanced at and on. So from here I want to just get a WildFire verdict or maybe open this environment total to actually see what WildFire told me about this and we've got a hit, it's malware. Now maybe that wasn't run on the box, maybe the attacker just put this on here and it was one of their tools that they used. We can download a report from WildFire that'll actually give us additional detail about this host, as well as other things or items of interest that we may want to go look for based on the characteristics that WildFire has already bubbled up for us. Now that I’ve download documents 7-Zip, I can go ahead and start to look and see what's in that file. Unfortunately I was able to confirm that those same files I saw in the documents directory were actually in this document's .7-Zip file. So I'd certainly want to look at my firewall blogs, or full packet capture solutions, if you're leveraging those or anything else that has any kind of visibility on the network side to see if this archive actually left your organization. You'll also notice here that there's a command line Python and power shell interpreter on all remote hosts available to you in the live terminal. My last step as the adversary is to cover my tracks, so I'll first delete all event log messages related to the attack. And then the next thing that I'll do, is change all timestamps because oftentimes during forensics investigations, investigators will overlook really old files, really old DLLs, really old executables and so if I change the dates of files to be several years in the past, all those files will be overlooked by investigators. The last thing I want to do here is try and find if this attacker tried to clean up their tracks. Not many organizations will actually log from individual endpoints. Many will log from servers to a SAM or other central for log aggregation tool. However, sometimes it becomes cumbersome to actually log from the implant itself. So similar to what I did before with looking for particular key words within command syntax, I'm going to look for anything that contained the line "ClearEventLog". I go ahead and look and show my results here. I can actually start to see where the attacker laid out these commands. I can see where a command shell was opened and there's actually some behavioral indicators of compromise that will bubble this up and generate an alert. You can also see the actual command line syntax, where the attacker cleared the security logs, the system logs and the application logs. You can also notice up here a file called log host dot log, that set file time to timestamps that look like they're a little bit older in the future. The next step as a security practitioner and a threat hunter, I would want to pull this log hosts dot log and figure out what that application is. I'd also want to triage across my environment to see where else I've seen in this binary. Now from here, based on what some of the things you've seen the attacker do, the attacker has leveraged that temp directory heavily. They've leveraged putty, they've aired registry keys and some of those will have very specific unique values. For example, the IP address that was used within the registry key. You can continue to search across your environment for that indicator, you can also put that into a SIM solution, check firewall logs or any other source that might have data related to IP addresses. You can also add these in Cortex under IOCs. That way if there's a network connection that seemed from any box to that particular IP address be immediately alerted giving you the ability to react quickly. In summary, we've been able to track an attacker from start to finish. From the moment that attacker landed on the box using legitimate credentials, we were able to hunt down based on behavior that may not be normal for individuals within this particular organization. We were helped with alerts along the way to bubble up that behavior and were able to attract the attacker moving files and toolkits, setting up scheduled tasks, adding files to archives and cleaning up their tracks. Although we highlighted this in Cortex XCR, these same types of logic and the same types of workflows work across whatever tools you may have within your organization to pull this type of data. There's a ton of tools out there that are available, that are open source as well as freeware as well as enterprise solutions that many different vendors sell. You'll need to look and see what works best with your process, workflow and team. And whatever you can do to automate some of this response or hunting and build what you find in your process would be extremely beneficial to ensure you're only hunting for new threats and identifying threats that have already been hunted and identified. So Mike, we've reviewed several of the key ways to detect an attacker with threat hunting. Once you found an attacker, how do you go about triaging the threat? So triaging the threat you really want to think about devices and identities, because an attacker is going in, they're using someone's identity to move around your organization, they're touching different devices. So you really want to focus a lot of your effort there. So one of the first things I'll do is go through logs or if you have an endpoint solution, depending on what tools you have in your environment, look at every single device that you've seen touched so far. Now if you need to go farther and wider, sometimes you'll get into an organization that maybe doesn't have logs or data that goes back that far. I've seen attackers, that may trench for three, four, five years within organization Obviously they don't have the data that goes back that far. There are some creative tricks you can use. Like one that I've had a lot of success with in the past is, whenever a new user logs in a new account and you see that windows is now loading your great experience, there's some artifacts that are made. So depending on what kind of tools you have, or if you could use the tools that are readily available from Microsoft, you can start to look for some of those artifacts. An ntuser.dat file always lives in a certain structure where it's C:/windows, whatever the username is and ntuser.dat. So if you see that that particular file exists, then you know that particular identity has touched that particular machine and it gives you another place to kind of jump off and keep going from there. When you're triaging, you just want to make sure, you include everything that you possibly can in scope. Once you start doing that you and have devices or particular identities of interest, you want to start pulling your Shimcache, master file table, registry hives, anything that can give you more detail as to what happened during that particular attack. So while you're triaging NAPT, how do you determine who's behind the attack? Yeah, that's a great question. So attribution is really hard, it's very easy to get wrong, so you want to be very careful. A lot of the characteristics people would use to attribute something to a particular attacker, or attack campaign can be easily spoofed. Maybe the particular toolkit that's associated with a particular group, country or threat actor, you know, was once uniquely used by that group, but now is widely adopted by a number of different attackers. Another thing that could be used is default keyboard language. So maybe you see an attacker using Russian, but there's plenty of people that speak Russian in China or other countries across the globe. So that might not be a very good indicator. The net is attribution is really hard, you want to be very careful. You can always build a theory around what the motives were and who might be associated with that campaign, but it is difficult and people do get it wrong. That's true. So regardless of whether or not they can determine who's behind the attack, once an attack happens, how should organizations go about responding to the attack? Everyone's going to want to have a knee-jerk reaction as soon as they see that, let's pull the plug, let's make sure we eradicate these guys and get them out of here. But the challenge is, these particular actors, they don't have just one particular piece of malware that they're leveraging. They don't have just one point of entry. Typically they'll use multiple toolkits, they'll have multiple points of entry. So the first thing you want to do is try and understand this particular actor's objectives. Once you understand their objectives, you can start to build a plan around how to remediate them. You can continue to do mass triage, certainly recommend calling in for help. Maybe that's consultants, law enforcement, vendors, partner organizations you work with. It's always great to have perspective from someone else's point of view that doesn't necessarily know your environment and maybe thinks about things in a little bit different manner than most. While you're investigating and responding to attack, there's lots of different tools you can use. What are some of the tools that you use when you're both investigating as well as hunting for threats? Yeah, that's a great question. So there's lots of freeware tools that are out there and available that are out there security practitioners have put together. SANS does a great job with their sift workstation of having an aggregation of a lot of those tools and scripts and some of the other things that are out there. And then obviously there are commercially available tools, Cortex XDR and as well as some of the Palo Alto suite of products as well. I'm very fond of those for obvious reasons. Great. And that actually leads us well into our next topic, which is to look at some of the tools that you can use to prevent attacks well as to hunt, detect, investigate and respond to attacks. So let's take a look at some now. Many security teams that we talk to are overwhelmed by too many inaccurate and incomplete alerts, too many manual tasks and too many siloed tools that they need to manage. And the threat hunters do not have the right visibility, they need to effectively find attacks. Palo Alto networks wanted to solve these challenges with Cortex XDR. Cortex XDR is the world's first cloud-based detection and response product that combines network, endpoint and cloud data together to stop attacks. Cortex starts by stitching data from our Next-Generation firewalls, our Traps Endpoint Protection agents and our cloud security products like our VM series, virtual firewalls and Prisma Access or cloud-based service that really helps extend our security to mobile users and branch offices. We stitch this data together and then we analyze this data including event data as well as threats with analytics and custom roles to help us uncover and prioritize attacks. Cortex XCR tightly integrates with enforcement points, so that security teams can contain threats quickly. By collecting all of our data in one place, we can provide also a powerful platform for threat hunting. The heart of our detection and response is really our data. And so to that end, we have developed patented technology that not only provides visibility across managed and unmanaged devices, but it also stitches together the data we need to deliver a complete picture of an incident. So we offer thread level visibility and that allows us to figure out which process launched another process. And that provides us the ability to show the root cause of attacks instead of overwhelming analysts with complex process trees. We can also stitch endpoint data to network and cloud data as well as to threat intelligence information. And because our firewalls collect user ID and app ID information, we can augment the rich data that we already obtained from the end point. And this allows us to more accurately detect stealthy attacks and to provide complete context for investigations. As an example, we can show which endpoint processes were responsible for a firewall security alert with just one click. In addition to threat hunting and to custom and predefined rules that we offer, we also provide behavioral analytics and that allows us to uncover stealthy attacks that may not even involve malware. So for example, we can monitor user and device activity and we can see, basically classify which devices are, you know, PC’s, which devices are phones, which devices are file servers or vulnerability scanners or mail servers. And we can also figure out which users are standard users and which users are IT administrators based on their activity, based on fingerprints in their traffic. And this classification allows us to filter out false positives and to differentiate between unusual activity and attacks. We can also profile the behavior of devices, users and groups over time. So we can look at how much data each device sends. We can look at what protocols each device or user uses. We can see how many hosts they connect to and what application servers they connect to. And we can compare current activity to past activity as well as to peer activity to detect attacks. So in this example, we have seen a device connect repeatedly to a site on the internet that no one else in the organization is accessing. And that by itself may not be enough, but we can also look at indicators like how recently a domain was registered and whether the site is hosted on a bulletproof hosting provider to provide additional context to find command and control servers. In this case, we also detected multiple failed DNS requests as well as multiple DNS requests for random-looking domain names, which would all be unique alerts. And by profiling the activity, we can see what's unusual and what's not, to more accurately detect this type of malware activity, which in this case would be indicative of domain generation algorithm as malware attempts to connect out to a command and control server. So Cortex XDR provides everything you need to secure your organization. First, it prevents attacks with market-leading network endpoint and cloud security. So with Traps, which is included with Cortex XDR as well as with our firewalls, Prisma Access and our virtual VM series firewalls, we can stop everything that we possibly can in real time. But for the things that can't be stopped in real time, we can automatically detect them by analyzing data over time with behavioral analytics and with customizable rules. We also offer threat hunting so that analysts can manually scout out those hard-to-find attacks. We can help rapidly investigate threats with our root cause analysis and our timeline analysis as well as our integrated threat intelligence. So we can integrate with our own auto-focus threat intelligence service and we can also integrate with third party services, like VirusTotal to get additional attribution data that can help analysts investigate threats quickly. And then we can also respond and adapt to threats. So Cortex XDR can integrate with enforcement points, including our firewalls, including all of our endpoint and cloud security products to stop attacks. We can also integrate with Demisto, which is our security automation and orchestration platform, and that can allow us to work with third party tools for response and remediation. So overall Cortex XDR can be that tool that can simplify your security operations and keep your organization safe. We have provided an overview of threat hunting and an attack simulation and shown you how you can hunt down those attacks. Now let's open it up for questions. If you haven't already, please submit your questions into the questions panel. Okay. So looks like we have received several questions from the audience. You have a couple minutes now if you have additional questions to throw them into the questions panel. So I will read through them right now. The first one is, I think this came in early and it may have been answered during the webinar, but I will repeat it. Is Cortex an interface into Traps data? And the answer is, yes, it is a detection and response service that can analyze data from our Traps endpoint agent as well as from our firewall, as well as from Prisma Access and VM series firewalls. The second question is a comment regarding the screen size and I think hopefully everyone saw the message to increase your screen size, so you could see all the text during the webinar. But if you had trouble and you really want to get that information, then contact us after the webinar and we will provide you access to a higher res version and we'll try to get a higher res version on the on demand version as well. And you can just spit your information through the panel to get that access. And then the next question is, a question I think for Mike and it is, how do you research the latest attack tactics and tools? Well, that's a great question. So there's a couple of different ways that you can gain additional insight into the latest tactics and tools. The first way is to crowd source that information. So blogs that vendors will put out on the internet, obviously if, if you're working incidents in-house, there's always the opportunity to see maybe new tools are popped up, new techniques as well. If you're, you're hunting on prem, I also very strongly recommend within your industry or vertical being aligned with some of the i-sacs. So in the financial services, the FSI i-sacs as well as the aviation i-sacs. outside of actually threat hunting in your own environment, looking for threats and responding to investigations. Those are a great closed source way to get high fidelity information about some of the new tools and tactics that you might see out there. Okay. The next question is, and I'll give it to Mike, but I might also answer it. The question is do you offer any type of education packages with certifications upon completion? So we do have certifications associated with Palo Alto, specifically Traps. Some of those certifications are being updated to reflect the Cortex XDR data as well. And I'll just add, we do have trainings specific to Cortex XDR as well as Traps, so you can learn more about those products. The next question is, can Cortex XDR detect tactics specified in the MITRE ATT&CK framework? And the answer to that, I'll answer it, is yes. We were one of several vendors that were evaluated in the first round of testing for the MITRE ATT&CK framework. And we actually, although MITRE doesn't really rate or rank the vendors we did, in terms of the number of attack techniques, we detected the most and we also detected the most attacks in real time. And we have a couple of resources including one of the attachments to this webinar, which is a white paper discussing our results and other results for the MITRE ATT&CK framework. So, I think it's titled “How to pick a winner for EDR”. So if you want to find out more, download that or watch a webinar that we recently broadcasted on that subject, which we can give you a link to. The next question is this, you already have automated detection in place, do you still need threat hunting? And I'll pose that to Mike. So the answer to that is, absolutely, yes. Automated detection is great for identifying things that we've already seen or tools that have specific models that look for anomalies or things that deviate from the norms. Those tools are still built on models and those models are built on things that we know, they can help us to bubble up maybe things that weren't static indicators like IP addresses and domain names. However, threat hunting is still extremely valuable to find those unknowns that you've never seen within your environment before Maybe a new technique or tactic that an attacker is using living off the land. So yes, absolutely you're going to want to leverage threat hanging along with whatever else you're doing today that's working in your SOC. So the next question, I'm going to reword it bit, but it's asking about certifications and we are certified and are in the process of getting additional certifications. And among other things we are SOC 2 Type 2 plus compliant our data center. And then we also are in the process of getting FedRAMP certified. So we're in the final throws of that certification process. And if you have additional questions about certification, again put it in the questions panel with your name and your email address and we can follow up with you with more details. And then I think the last question, is, what type of data is the most valuable for threat hunting? So great question. Threat hunting is all about sifting through a ton of different data and different types of data give you different vantage points. And there is some overlap in those. So, for example, tools that are on the endpoint will give you specific data about, you know, maybe what process executed or was a file written. Packet data will give you an idea of what actually went over the wire. And then logs can help tell you maybe other events where you don't necessarily have endpoints so local authentication to Windows boxes, or failed offs across network or even logs from devices that may not have an end user associated with them, like routers, switches, things like that. All those are very valuable pieces of information and all together will put together a puzzle for you but are each unique pieces and very valuable. So I would sum it up as probably endpoint and log data as being the most valuable. But absolutely having packet capture data as well, to see what actually went across the wire is huge, especially when you're in a situation where you might be dealing with an attacker that is in your environment, an active attacker within your environment. Okay. So I think that wraps it up in terms of questions. So thank you everyone for attending this webinar.

Video Details

Duration: 52 minutes and 45 seconds
Language: English
License: Dotsub - Standard License
Genre: None
Views: 21
Posted by: zeitgeistuser1 on Oct 16, 2019


Caption and Translate

    Sign In/Register for Dotsub above to caption this video.