 Welcome to the project obsidian incident response module today. The title of our talk is it all starts here scoping an incident where I will be going into detail about how to scope an incident and triage before you actually jump into the real meat of the analysis. So with that I'm going to be going into a little bit of background about the kind of resources and different portions of this talk so that everybody's kind of on the same page as they get into the actual scoping and triage conversations a little bit later on. The first one is really around the investigator mindset. This is not anything new. I think most of us kind of naturally do this but this is really just putting words to that thought process. So the first thing is really understanding that whenever you're going into an investigation that you should be creating some kind of hypothesis. It's not always very obvious it's not always very clear on what you should questions you should be asking but the more you do this I think you kind of get that feeling of, oh this looks like acts because of this, or this looks like initial access through RDP or this looks like ransomware. As you do more and more investigations you kind of get that understanding of what something may be and you can create good hypothesis which then leads to a more structured and strategic analysis versus just jumping into something and not really having an idea of where to start looking. So, of course, step number one, creating hypothesis. Moving on past that is really understanding what evidence you're going to need to prove it. So of course you can have any hypothesis in the world, but if you want to prove anything in IR, you need the evidence to back it up. So as you are going through this you also need to understand what type of evidence you are going to be able to prove that RDP took place, or that this phishing email is malicious how do you prove that this is actually something that is malicious versus just stating that as your opinion. And then step number three, which is almost more important is determining if that evidence is even attainable are there logs in place to be able to prove that this happened. Can you prove that that domain was malicious. Can you prove that these emails were sent externally whatever it may be you need to be able to prove what actually happened with the evidence that you have in hand. And in some cases you may not have any evidence at all. So then you move into step four which I think where most people tend to jump right in is just reviewing and analyzing the actual evidence itself. This is something that I think a lot of people enjoy doing this is what we talk about when we're talking about technical investigation. But a lot of times when you're doing this you are missing out on a lot of good detail that could be gathered if you just took the time to step back and understand what type of evidence would even be helpful to understand the situation. And then step number five, the last thing you do once you have a hypothesis is proving it, whether it is correct. It is incorrect. Or the last one that I think a lot of people forget about. Is it unable to be determined. That's portion comes up a lot more an IR that you would think a lot of times we have to create some kind of conclusion that we can't really determine what happened. And the key to this is being able to determine why you can't determine what happened. Is it because you don't know the evidence that you would need to prove it or maybe the evidence you do know, but it is just unattainable at the time. That's why step two and three years so important to this because oftentimes if you can't do step two or three, it jumps right into unable to be determined, and nobody likes that answer. So we can give the answer of we can't determine the evidence, but if we had this evidence source, we would be able to find it. It still gives some kind of action that can be taken place versus just saying, I don't know, throwing your hands up. Beyond that, I want to talk a little bit about the different life cycles that are common in IR. Of course, the incident response for life cycle is bread and butter is what you're going to need to know no matter what's going on, which is preparation, detection analysis, containment, recovery, and then post incident activities. I won't jump too much into each one of these quite yet, but some of the other talks will be going into a little bit more detail of what each of these truly mean. What I'm going to be focused on is actually how you move from preparation, which is anytime you're not an incident you should be preparing for an incident to detection analysis. Is it just a matter of starting, what do you do, how do I start. That's the question I'm here to answer. And then MITRE, if you're not familiar with MITRE, I would highly, highly, highly recommend you go get familiar with MITRE. It is quickly becoming kind of the industry standard in a way. It's a collection of different adversary tactics, techniques and procedures before the turn TGPs before this is kind of where that originates from. The tactics, techniques and procedures at a high level tactic is the goal of the adversary, what they're trying to achieve. The technique is the actual process they're using to obtain that goal. And then the procedure is the very specifics of what exactly they're doing and potentially the differences in procedures you may see depending on which third actors involved or which type of technique is utilized. So, like I mentioned before, my main goal here is how do you move from preparation to detection analysis. Because it's easy to say, maybe you just start looking, but what does that truly mean? Well, that's where these two things come in, scoping and triage. Scoping is understanding all the known facts and what the impact is at the current state. You aren't going to necessarily know everything at the beginning of an incident, but you can take the time to understand all the known facts currently. Because a lot of times you are going to miss things when you're jumping into an incident and going straight into analysis. Because yes, that is definitely the fun portion, but it is not the most important portion, depending on what your objective is. Then the next portion we go into is triage. And triage really isn't necessarily analysis, it's pre-analysis in a way. It's the initial analysis you do to gather the appropriate leads so that you can create a proper investigation plan and give people clear objectives on what they should be looking for. Nobody likes going into an investigation where they know nothing because you end up just looking and looking and looking until maybe something hits. And then once you get that hit, you kind of pivot and pivot until you can answer the question. This is very similar in process, but what we're doing is once we find that lead, we note it down as something to investigate and then look for additional leads. And then once we've gotten everything together, we start doing a much broader and stronger analysis and we can compare notes and see what actually took place here. So with that, I'm going to jump right into scoping. So incident scoping for a quick definition is really understanding what happened at the current state. This isn't necessarily always something you have to do, but I always urge that it's something you do no matter the type of incident you're dealing with. You should always gather as much information as possible early on because it is likely that those sources of evidence or those sources of information for the incident are going to go away the further and further. We delve into the incident as time goes on. So one of the first things you should obviously always try to figure out is determine if that incident should even be considered an incident. Is it just a security event, or is it a full blown incident. And one of the questions that I like to ask with this is have you seen this before, because if you've seen this before, it could still definitely be an incident. But a lot of times it is likely something that is common, maybe misconfiguration, maybe something that just needs to be fixed that hasn't been fixed yet. But make sure you ask the question because I've been a part of a lot of investigations where we just start and we've considered an incident from the get go. And as soon as we do, we find out about, you know, a day and a half later that Oh, this was actually just a misconfiguration that was not fixed in time. So you want to make sure that you take the time to ask this question and really consider is this an incident. If you don't have classifications that exist today to properly say whether something is an incident, or it is a security event, or assigning some level of severity to it. That is something you should definitely look into, because if you can do that makes it even better. That way you could say if it's a medium or high level threat, then we will say as an incident if it is a low level threat, and we will say it will proceed as a normal security event. Then moving on from there is really understanding the incident and what needs to be done. So figure out what exactly is going on, and what is the end goal. And then we jump into these things and we don't have a goal in mind. We don't know what it is that we want done as a result of finding all this information. But if you talk to people they kind of already have that in their head, but it really just depend on your role. An analyst may want to figure out how does this malware work. They want to see the intricacies of what it does and seeing if they can create proper detections around it. So may say, hey, I want to figure out if there's any reason that we should be considering some kind of compliance notification. Is there any reason that legal should be involved. Well, the manager may say, hey, I want to know how long are these systems going to be down. When am I going to be back up. And what is it going to take to prevent this from happening again. Everyone is going to have different types of questions and different types of objectives that based on their role to making sure that you can clearly note those down of what people expect is really, really important. So make sure you understand that and don't assume someone's expectations, ask them, get it on writing, make sure it's noted down so people understand what their end goal is. And then using templates, which I will thankfully show you a couple examples here today. Using templates is going to save you a lot of time. Trying to jump into this with a blank piece of paper is scary. When you just open up an empty Word document and there's nothing on the page and you know you have to create a report is very tough, because you're going to miss a lot of details. You're not going to ask some of the right questions that you should be asking. So make sure you can note all these things down, have all these questions pre prepared for things that you commonly ask in these situations. That way, when you're going into an incident, you have them in front of you, you can walk up to the person, ask them the questions, write down the answers and fill in everything you need to do. And we'll kind of talk about that in a little second. Beyond that, once you've kind of gathered all the information that you need, and you go through this scoping document, which I'll show you in a second. Then you're going to be talking about how this investigation needs to proceed with your team members. And remember, your team members aren't necessarily just the security team, it isn't necessarily just the network team, it is the combination of whoever can help and provide value to that investigation. So make sure you gather everyone's notes. I personally like to have everybody kind of put their notes into one document or one location so everything can be looked through very easily, because people are going to have different perspectives. So making sure that you get all those different perspectives, put it into a single place that people can look through it and potentially get inspired on how the investigation should proceed. The next one is evidence sources. Evidence sources should be discussed early. I know it doesn't always seem like that. I know sometimes you kind of just go with it until you determine something and then you find the evidence source for it. But if you can do that in advance, create that hypothesis, determine what evidence sources you need for that hypothesis, you're going to be ahead of the game. You don't have to wait to tell the networking team to pull NetFlow data for three days, because that isn't something you can do very easily. You need to be able to pre-plan in your head and have an idea of what you expect what you would need. And again, a lot of this just comes with experience. You can also use things like MITRE. MITRE actually is a great source for evidence sources where they will detail out something like initial access, RDP, and they'll give you a couple of evidence sources of what you can look for to potentially be ahead of the game. So look through those types of things, use the resources available, and try to do two documents as much as you can early on. That way you're not looking back and trying to remember what evidence sources you wanted from the very beginning. And then confirming those objectives that we talked about. We're going to have different roles, people are going to have different objectives, be very clear on what those objectives are going to be. You can have multiple, that's fun, but making sure everyone understands them, and they can understand the goals that they need to try to go after. If the goal of the investigation is to determine data exfiltration, you may not need to spend as much time on the deep malware analysis. If you're looking for a ransomware executable, you're not going to spend nearly as much time looking for the decryptor if the goal is to see if data exfiltration took place in the first place. And then giving next steps for each IR team member. These next door kind of for whoever the incident commander is, whoever's kind of running the show. Make sure you give a clear task to each individual. And on that team should be able to leave that room knowing exactly what they need to do, not just go look, tell them to go look at Windows event logs. Go look at the network alerts that have came up in the last 30 days, give very clear instructions on what you would expect from them. Sometimes you may not have exactly what you need them to do, but take the time to try to get as much information and give as clear as instructions as you can. Otherwise, people are just going to endlessly pivot until they get tired, not having answers and kind of burnout before you can actually get any real analysis done. And the last step here is really establishing a communication cadence. So, once you've said, hey, go out and do these tasks. Give them a timeframe in which they should come back to you with something they don't have to have answers by that point. They're not going to have their analysis completed by that point. So, give a touch base so that you know how to go through these things, get the proper notes that you need to put them all down the way that looks beneficial. And then finally, you can use that information in these kind of either daily calls every four hours every eight hours, whatever your cadence may be. And you have a kind of set timeframe in your mind of when you should start to wrap up your investigation, collect your notes, and then maybe move to something else. So with that, I'm going to jump into my sample for these scoping notes. So with this, keep in mind, we're going to be going through kill chain one. We'll go into a lot more detail some of these other kill chains in different presentations and some of the specifics. But all you need to know for my example is that a phishing email has taken place and it looks to be impersonating the legal department. I'm going to jump over to here. You can see this is my template for scoping. It's not a detailed document. It's nothing super fancy. I'm not putting in special logos or graphics or anything like that. It's really just a way to organize my thoughts as I'm going through this. And I try to put a lot of these questions in order that makes sense as if you're interviewing someone. The questions are really all based around what are the types of questions that you're going to be asking someone or you want from them before you really, you know, start the interview process. So the first one of course is, you know, which organizations evolved with the key members, when was this reported, who is assigned, who's kind of aware of the incident going on, is there any special legal privileges that we need to be aware of. And the last question, which is probably the most important, what are the objectives? What do you need to know? And keep in mind, this is based on your first time talking or hearing about an incident. So you're not going to have all the answers right away. But having these pre-prepared gives you something to look at. So when you're at the end of the point of talking about whatever it is you need to with them, you can refer back to this document and say, okay, actually have a couple more questions and run through these. Then we get into the detection portion of things, which is where a lot of the meat of this comes from, because pretty much detection is why you're there. Somebody's detected something, rather than bringing you in to help investigate it. The first question here is, when was the incident detective? And this is a general statement. You know, you want the timeframe, but oftentimes I find when you ask this question or something similar, people will just start to talk. It will really just really go into all these details about things and describing the incident as much as they can from their head, which is fine. Don't interrupt them. Don't necessarily stop them and say, hey, I have very specific questions you need to go through. Allow them to talk, document as much as possible, and you might be able to answer a lot of these questions before you get to them. So take the time, use this first bullet point, and I would suggest as a incident summary bullet almost so that when you're getting all this information, you can write everything down and you can kind of move it throughout the document later if you really need to. So you can see all the questions here are dependent on detection. We really want to emphasize how are you, how was this detected? You know, was this a manual process? What kind of information was a part of the detection? I've noticed a lot of times that when you're working on a case, somebody may say, well, we had alerts triggered for a specific system. The problem is nobody actually looks at the actual alert until maybe, you know, a day or two into the investigation. But make sure you gather what's initially part of that detection in most cases. In this case, we see there is an email message and it's detailing a violation of an IT policy, requiring additional action. And then I actually took a screenshot of that actual email itself, which is to summarize since it's a little bit hard to read that a specific individual violated an IT policy. This is coming from the quote unquote legal department. And there's an attachment that needs to be reviewed as a secondary action as a result of this. So it looks pretty suspect. We want that information there. So that way, if we ever need to refer to it or find their original email, we actually have some information here that we could work from. And then the impact. In this case, there's not really too much impact right now. We just know the one email recipient, but obviously we want to expand that scope because it could be more. And you can see I put TVD here in terms of who else is impacted as far as the host or whatever systems. The goal of this document isn't necessarily to answer every single question. It's just to have those questions there so that you aren't missing things that otherwise could be useful. And then is there a unique identifier for the effective resources. The only thing we have right now is a specific email phishing was from this domain, which is magnum tempest that financial which is potentially a little suspect. And then we went to the actions basically to determining, you know, what has been done since this detection took place and any remediation been done. And then the environment itself, whether it's a specific department, if you're working from a consulting standpoint or you're working for another organization, understanding all these key details, but their tool sets users endpoints capabilities. So that you have other things potentially lean on if you run out of ideas. So what I'm going to ask you here really about the kind of IOC is the network and malware IOC is if they see enough alerts or something else already. This is kind of gathering additional information from that. And then the last thing is the next steps, this is essentially confirming those objectives, making sure you understand the objectives from whoever you are serving, whoever is kind of your boss, and what are your personal objectives. There are different angles you're taking objectives. So get them all noted down, determine the priority of them. And then you can move into the investigation back into here. All right. So now we are going to jump into triage speed up a little bit. So the first portion of triage of course is evidence collection, you know you have your scoping notes understood you have all the information that you can obtain at this point. So let's start to move into let's try to get some tree out of the analysis to establish some leads. So the first, firstly, collection of evidence has changed quite a bit these days. I mean, obviously before imaging and forensics was kind of the key with dead box forensics. But now things have changed quite a bit. You have imaging software, you have different types of triage scripts, you have security consoles to look through to gather information, log files and even virtual system files. And I noticed is actually pretty important in this from the console standard point is obtaining and providing access to these different consoles. You should have a process to provide access to individuals, such as an external firm that's helping with forensics, or potentially a different department that may be kind of supplementing to help out provide them access in a secure way for that you're not getting in the way of an investigation just because of a strange audit policy. Make sure you have these contingencies in place because this is often what causes a lot of investigations is they don't have access to the things that they need. And then clear instructions on how to preserve and prepare. This is more intended for the security teams. If you have a way you'd like to prepare evidence that you have all the data you need, collecting specific artifacts, performing the triage script or the imaging software in a very specific set of ways. Make sure you note those down and provide that to whoever may be doing because maybe in some cases the IT team may be gathering the system. So when you say hey take that system offline, let them know what you mean when you say take that system offline. Do you mean pulling the cord on the whole system. Do you mean just taking off Wi-Fi, pulling the network cable attached to it, or potentially running some type of software on it to prevent it from communicating with anything else. Make sure you're very clear about what your intentions are. Then pre-planning for analysis. The scope and timeframe of investigations has changed quite a bit. I think it was back in around 2018, the timeframe was around at least 180 days before malware was actually detected in the environment. And that was 2018, it was a while ago, but I think most of us can say that that isn't too different than it is today. We'll cut that in half and say today, it's 90 days. Even so, you want to make sure when you're gathering evidence you do that in mind. If you're seeing something like ransomware taking place, that's not an indication that ransomware took place today. That's an indication that somebody may have been in your environment for multiple days, if not months, if not maybe a whole year before getting to this point where they're executing malware. So make sure you understand the full scope of what you should be collecting, the idea that your current timeframe of when this first started may expand. The triage analysis. So when you're going into triage, make sure you organize and document everything that you're collecting. This can be tedious. This can be really annoying sometimes, but it's very, very important, especially when you're talking about investigation that is crucial to the legal or forensic side of the house. So making sure you document everything that you're collecting and why you're investigating it not only gives you coverage in terms of how you investigated, but also gives you coverage in terms of what needs to be done. Don't rush into investigation without a plan. A lot of people like to just get into investigation and pivot until they get too tired to understand what's going on. So make sure you have a very clear idea of what you need to be looking at, what evidence sources you should be looking at. Take a little time to do research and see like, hey, if this type of ransomware executed, what type of evidence should I be looking for. Taking those few moments to look for those evidence sources versus just jumping in and analyzing something that may be, you know, not very valuable in the long run is just going to waste your time and make you more and more tired and trying to figure out what's going on. And then last portion here is really just writing it down. Summarize what you are seeing, not just the bad stuff. If you're seeing commonalities if you're seeing a lot of activity around Google Drive that you know doesn't necessarily look malicious but is unusual. Make sure you note those things down. And more importantly, you just want to note things down that stand out. Do you have something that you would consider a finding. And it's tough to kind of verbalize what a finding is, but really, it's something that stands out to you, and I'll give you some ideas of how you should be documenting that. So how do you find evil, you know triage like we said it's not necessarily the, the true analysis that's going to take place but you still need to understand where to look to find commonalities. These are just a couple of things that I've noted down with these common indicators but the key ID here is malicious behavior is not going to always be identified when incident response is engaged. A lot of times people may say that there's been a ton of unusual network activity, or my system is extremely slow. And that may be enough to kick off an incident. So make sure you have a plan so that you can do your own version of a kind of threat hunt, because a lot of times it's going to be extremely necessary. And the best thing you can do for any type of incident is understanding a baseline. If you know what the common things that are run on a system is, then it's going to be much easier to find the things that stand out, because that's what's going to take place. Are you going to see strange connections? Are you going to see unusual processes, weird services, rogue accounts, unusual files that have strange naming conventions, or even some of the auto start locations that aren't commonly used. Knowing these things is what's going to help you figure out where the bad exists, because if they are just operating the same way as a typical user would, it wouldn't seem very malicious in the first place. And again, use your hypothesis approach. Look at these different paths. And sometimes you're going to find points to pivot on very quickly, but make sure you finish your hypothesis. Note something down as something to follow up on. And once you finish your hypothesis, move on to the next thing. You don't want to leave a bunch of thoughts just incomplete, because at the end of that you're not going to have much to report. You're just going to have a bunch of incomplete hypotheses that were never fully realized. So finding. So what determines the finding again changes. It's something that stands out to you. And it's okay. Sometimes you are going to come across findings that end up not being true findings. It's fine, but make sure you go through the proper process so that you can get better and better at it. These are the kind of six things I typically would say need to be included with a finding. One is the timestamp. One is the investigate or event description to describing what exactly you think you're seeing three, the data source, where are you getting this from. And with the data source, you also want to make sure you include the query or procedure and how you got to this point because you know just saying the the splunk console is not pretty much include the actual search in there or include whatever data source you needed to get that point. And then the context who what where when and why and if you can't answer all those. Maybe you need to do a little bit of research to see if this is something that is truly a finding. And then finally, the code, whether it's the file path registry and she copy of the command, whatever it may be, I always recommend having that in your actual notes, which will actually be your report. I'll talk about in a second to get all that information one place you don't want to have to say, well this is in the splunk query. If you query this this and this, then you can actually see it. Have a copy of it available so people can easily records it and then writing your findings. When you're writing down your findings make sure you write them in a report format. This isn't necessarily just to make things difficult for you. This is to ease it for you. So that eventually when you get to the end of this investigation, you have to write your report. There's not much you have to do. If you write your notes in this format, you are going to have it already ready as if you are having a report. So this is two things for you. One is the process of the report and it also eases the ability for you to speak on the findings as if it's a conversation. So write your notes as if you're trying to explain to somebody what you are seeing. That will make things much easier and I'll kind of find gaps of like, oh, I don't actually know this piece of information as far as what user ran this. So I need to figure that out. And then understanding your timestamps of your data source and you always try to convert to you to see if you're new to forensics. If you're new to incident response. Think everybody knows UTC is came convert everything to the UTC zone time zone as much as possible because it will make time lining and creating all these different things so much easier. Now, I'm going to go through my investigation notes. So again, similar type of thing investigation notes are not anything overly complex. It's just a simple document to gather all the different areas. I personally like organizing it by the different consoles and logs you can go through and then going into the host and then having a small section for indicators. I do it this way that way you can kind of separate things out based on specific hosts, but you know if you're looking at a wide scale investigation where you have 300 hosts that you're looking at then you can maybe do it by a specific indicator or something similar. So in this case, we're looking at kill chain one again, we're looking at email. At this point we don't have to many notes right we just looked at the scoping and we have a couple beats of the data to add in here. And you can see I'm writing this in a very explanatory way I want someone to be able to read this and be able to basically state what my investigation is. So at this time frame 2020 to 12 to 2110 06, which is UTC, because it's in that format. The team identified a suspicious email with the subject line action required organization it policy violation. The email originated from the legal team legal internal at Magnus Tempest financial, which the team validated was not a legitimate organization domain, the email received by Amanda new and new instances. And the team is filing validating whether any similar emails were sent to other users, the contents of the email are noted below. Then a quick conclusion at the contents of the email period to attempt here to attempt the course, the employee into reviewing a fake it policy violation by reviewing an attachment to email. That is written in that format. These are my notes. This is not a report. This is essentially when I want to include in my notes. That way when I go through here, I have a lot of information I can already look through subject client action required organization it policy that gives me something to search on. I've listed out the important domain here which appears suspect I've listed out the username though it's affected. And all this information is put into a nice little paragraph format so if someone said to me, hey, can you give me a quick write up on what happened. Copy, paste, we're done. There's nothing else to do. You do this with each one of your findings, you're going to have a exceptional well written report at the end of all this. Beyond that, you can see the hosts are organizing the information in a similar way. The only difference here is that you have the host some information about it, and I specify everything by the artifact. So for example, the windows event logs, and then I'll have a section of this event logs, or the MFT and I have that section on the MFT. Then at the very bottom, I like to include the indicators. So, this is including all the different types of information indicators are organized by network file and the affected users or associated users should say. So the IP address or DNS we know about right now the domain Magnus Tempest Financial. And I give a quick description basically saying hey it's a donate name associated with the center of a fake it policy violation. So we know at this point. File nothing associated currently at this point, we know that there was an attachment that's something that needs to be reviewed. And then the users. So we know that there was a legal internal for Magnus Tempest Financial, which was the center, and then the Amanda newness account, which was the receive it. So this, the reason I do it this way is if someone needed information to search on or you wanted to do some intelligence work, you can utilize the section to quickly kind of dissect that information and look to see. Is there anything else that we should be searching on. And that's it. It's nothing overly complex it's nothing incredible or you know it's not the most, you know detailed report in the world that goes into all these specifics you can definitely be even more detailed that I am here. It just gives you a starting point on where you should be looking for. So with that, my final piece of advice I hope you kind of learned a little bit you got some information that you can utilize in your investigations. I mean, obviously this topic is something I could go on for days if not years about. So please if you have any questions. Please let any other team members know and they can give you my information in a way that you can contact me and we can talk through this. But my final piece of advice here, take a breath. Pat yourself on the back these investigations are tough and can take a lot of you. These steps I described are not necessarily easy to do. It's something that takes time as you go over over and over and over again, where you get into a flow state of how to do this time and time again. Next thing is really step away from things. I can't tell you how many investigations I've been on thinking I'm so close to figuring something out. And I take a quick 20 minute walk, come back to my system, open it up and I'm like, oh, there's the answer right there. Sometimes you just need to give your brain a little bit of time to recharge get back to that point that you need to, and then you will be good to go. Knowing your limits. This one's tough. Understanding where you exceed and where you may need help. For example, for myself, I'm not the best at deep malware analysis. So I know if I'm getting into a situation where I find some malware, I can do a little bit of analysis, but ultimately I may say, hey, I need to bring in someone else that can do stronger analysis. That is what's going to make your team stronger. You want to be able to do as much as possible, but you don't need to do everything. You have limits. Everyone has limits. Try to divvy it up as much as possible in a way that everybody can succeed and get the answers that we need. And again, the last thing here is ask for help, whether it's about this presentation itself and understanding the steps to it, whether it's figuring out details on how to do investigations better, whether it's you just don't have the time and you don't know if you're looking at the right things, ask for help. It's fine. All of us go through this. This isn't new. The more you can ask these types of things, it just makes you better at what you do. So the next time it comes up, you know exactly what to do and you're going to be the person helping others. So with that, I appreciate everyone's time. And again, if you have any questions for me, please let one of the team members know, and I'm sure they can get you my information if you really need it, or you can ask any of their team members they're all exceptional people here that know all about incident response. So, enjoy your time here we'll go through some of the other modules and some of the other talks and, as you learn things, you get better and better at what you do. So, thanks again for your time, and we will be going into the next section after this, shortly after.