 Welcome everyone. This is our module three session on generating threat intelligence from an incident. This session uses data from kill chain one, which will be made publicly available, and demonstrates how we can generate in generate intelligence from an incident or intrusion and use that data internally. Advancing the slides. So, we will touch base on our objective. And we're going to iterate we're going to run through the CTI life cycle here. We're going to start by touching on our stakeholders requirements goals and objectives. And we're going to get into the CTI analyst role during an incident and talk a little bit about processing intrusion data and information. And the bulk of the conversation really is going to be around analysis and production, the research and elements to include in a CTI report. And we'll touch briefly on dissemination how we're going to share this and you were going to share this with, and finally we'll wrap things up with feedback and evaluation a critical step in the CTI life cycle and CTI program in general. So we'll, we'll touch base on that here as well. The objective is really straightforward. We're going to demonstrate the important role that CTI plays both during and after an incident and moving right along into planning and direction. I'll go ahead and pass it over to Stephanie. Great. So we're going to do an overview of the stakeholders in this scenario. So the stakeholders for this kill chain are our CISO, the CTO, the CIO and executive board. We have people sitting in the SOC. So the defenders, forensics team, instant response malware analysis and threat hunting teams. We have SOC management and the IT team. And this phase of the CTI life cycle is where our requirements are created. So we can see here in this diagram, some of our goals and objectives. So we want to identify blind spots in our network, how we're getting attacked so in our endpoints network platforms. We want to understand the adversaries capabilities. How are they attacking us? Why? What is their method of attacking us? And we want to also call out explicitly any new kind of defense mechanisms we want to create because of this CTI life cycle we're going through. So those might be new detections we write, new threat hunts, new purple team test cases. So those might be explicit test cases you run with your purple team to check if a certain blind spot has been covered or not by your defenses. And while performing research isn't necessarily a stakeholder requirement, the CTI team should be digging into those IOCs to find new information that they can use to inform the various teams. So we can use different tools and analytical methods for this kind of research. And back over to Clay. Alright, so yeah so touching on collection here. Right so artifacts will be collected from different teams that are going to be involved during the course of an incident. This will be our IR team, our forensics team, and even our malware analysis team who might get some artifacts from the forensics team. So all all of these teams work together and there might be, you know, some people might be on multiple teams. So every organization this will this will look different. So additional data and information will come from external sources through OSINT on existing data. So OSINT includes sources documented in our collections management framework or collection management framework that that we've created. But we'll also include sources that are discovered through the process of pivoting, which we'll touch on in a little bit. So existing data plays a critical role during OSINT. When we're pivoting when we're using open source intelligence. We might not know what data source we're going to run across that might be useful. For example, it could be as it could be an article or a in depth malware analysis report that we find useful. So during OSINT. Yes, we'll go rely on our platforms that we're aware of and that we've documented in the CMF. But at the same time we're also going to be performing research that's going to lead us to new data data sources that will pull those in as well. I just wanted to note on all of that processing. So this is the next phase in the CTF life cycle and we'll be using intrusion data and information for this. Now every organization will be different and depending on the level of maturity the organization has this could be very limited or quite verbose. Tips are commonly used so the tip is a threat intelligence platform for processing and open CTI is a free and open source platform and here's just a quote pulled from from their website. And yeah it's a great way just to structure store organize and visualize technical and non technical information about threats. Automation of data from a tip to a sim is another commonly implemented process. And as we're working through these events or intrusions the daily work we do. Look for opportunities to develop this phase of the CTI life cycle and ideas will come at random times. You never know when an idea is going to strike or present themselves. But make notes document those and you know that way it'll you'll you'll make improvements along the way. So now we'll get into analysis and production and for that I'll kick it over to Lucid. All righty. So analysis happens during and in support in during an incident, and this could be to support other teams, and it produces CTI that will actually be in reporting. And the CTI team can really add value by analyzing OSINT. So we're moving through IOC's like was was already mentioned, you know an open source intelligence can be visualized and analyzed a lot of different tools platforms and models. And I'll have a demo here of a couple of those tools virus total and any run which provide sandboxing and visualization of IOC's. I just want to highlight a couple of open source intelligence tools that we can use. Maybe if we have an active incident and we've been provided some IOC's, we can see what's publicly available about those those IOC's and see if we can discover infrastructure or tactics or other things that could help us to help the other teams in incident response threat hunting to respond to an incident. So in this case, the situation is that the incident response team has provided us with a domain. A user has clicked an attachment and an email and it really wasn't what they were expecting. And they reported it and firewall log showed that this domain baseball charlamagnelegardier.com was contacted. So we do a little bit of Googling first. Okay, this looks like might be a real maybe French baseball team. So maybe this site isn't infrastructure that was set up by a threat actor could have maybe been compromised if this is really a malicious site is suspicious at this point. We can see an alien vault, which is another provider of open source intelligence shows that this is probably a WordPress page. It's got this WP content in the links that we see here, the associated URLs. So maybe it's a compromised WordPress site. We'll see maybe we'll see nothing. When we look at virus total virus total sandboxes URLs and files that people upload and then comes up with a report essentially of all of the behavior from those executions. So if we look here, we can see that the domain itself is actually considered malicious by some security vendors six out of the 94. As we go through the tabs, there's some more information about the domain. Some relations. This is really with bread and butter here virus total where it shows some of the behavior and and other relationships between this domain and other files. That contain this domain and their tech in that in the file itself files that when run communicated with this domain. But really the best the best visualization of all of this information is to use the virus total graph. Now you can create this graph after setting up a free account and we can look right away and see, okay, something must be wrong. There are in fact document files that communicate doc and XLS Excel spreadsheets that communicate with this suspicious domain. Now we already have more information than we started with. But we can start to look over the graph and we can see that these documents are considered malicious by security vendors by different antivirus engines. And we can really start to pivot from here. We can find a document that's considered malicious and see what its other relationships are and expand those out. These aren't expanded right now. So for instance, if we expand domains, we will see that there's some other domains that get contacted when this document's opened. Some of them are related to Microsoft. So those might aren't really suspicious. But there's other ones like this domain tango with Colette. And we can really just continue to expand because if there's there may be other documents that also communicate with with this with this domain tango with Colette. So we're going to find some additional documents. So this might give us, you know, tango with Colette. That's a pivot to infrastructure from and we pivoted from that infrastructure potentially to more tactics to abilities that the actor has based on, you know, the the results of these are executed in the sandbox. This is already a lot of information that we could pass back to the other teams. We can really keep going. We can look around the graph and see that there is also this PowerShell script. It's not quite obvious from looking at that it is a file name that it's PowerShell script. But we could see that it is executed by several of these files that communicate with the domain, the suspicious domain that we've been given. So maybe our teams are going to start looking for PowerShell scripts in their in their tools, their on premise tools. And another thing we can do is that we can take a document that is has relations to this, what looks like a campaign. And we can run it through any run. Now any run is also a sandbox, but it will show and play back it was interactive. First of all, when you run the file, you're able to interact with it in a virtual machine in a sandbox. But then after the fact, it creates a report and a link back to that session shows what happened in real time. So in this case, we can really just look back through all the public tasks to see if a file of that hash was run through any run. Now we can see that there's a bunch of different runs. This is a historic campaign from a threat actor Lazarus group. And we can see that some of these may be more or less complete as far as whether it act the files actually reached out and downloaded a malicious payload just in that there could be all kinds of reasons for that. But this one here is probably the most complete run. And we can see on the right here, the exact timings of the fact that Windows Microsoft Word ran and that exploit of some sort caused this power shell to execute. And we can see more information about this power shell itself and all the different events that happened as a result. We can get a PCAP that's actually a capture all the network traffic that was generated from this session. We can see all the connections here and look through them and see if there's any other domains maybe that we missed when there's actually this towing operations. There's another domain here that we actually didn't miss. I don't know that we necessarily saw that on our graph over here. So, as you take bits and pieces that you get from one tool, you can put them into another, and you can find out more information that you can pass back as a list of IOCs to be very useful to threat hunting and everybody else that's responding to an incident. That is my demo of virus total and any run. So this graphic focuses on the production element of the phase. And this can be a template it's just it shows some of the things that go on a report it's not doesn't limit you to just these items. You know the graphic section doesn't just show all it's not live doesn't you're not limited to these graphics, but you could put things on there like a multi graph, or just diamond model. But this is a good visualization of all the things that would go on the report. And you're thinking about with a complete report does it tell, or if you're thinking about whether to put something on the report as completing it you're trying to ask the question does it help to tell the story. So, one of the things from the previous slide the diamond model for intrusion analysis. This can be used both track contract both fail or successful intrusions. And it models the relationship between data points. And it helps with pivoting testing theories about how things are connected or how an intrusion happened. So in this example, the anti virus on a endpoint within the organization detects a scheduled tasks that might be suspicious. The information is passed a threat hunting team that discovers a mal doc malicious document that communicates with infrastructure you see on the left of the diagram. We're able to resolve that IP to a domain name, and that domain name we don't know who the adversary is, we're just going to use it to define our adversary. So because we had malware love that XYZ. We're just going to call this cluster of activity. And we can do this use this model to perform analysis periodically, whatever schedule makes sense for the organization. The other way to show the data. An intrusion is an intrusion summary. This is just a listing of all the different data points from the previous graph same information. The intrusion summaries inside an organization are really the best source of intelligence show what's actually going on with that company with thousands of attacks going on outside of the organization data, even in a single day. And the diamond model to visualize the data points from the summaries. And then you can start to see clusters of activity emerge from this process of going from a summary to a way of modeling or visualizing the data to starting to see patterns. The MITRE attack navigator. This is a web based tool. It's free for annotating and exploring these matrices. You can visualize your defensive coverage plan for red or blue team activities purple team. And this is this this visual is a heat map of TTPs that were part of kill chain one. This is an example. We, there's not every, not everything that happened in kill chain one is on here. Not all of the little sub methods are on here. You'll be able to with a read. There is a link at the end of the presentation, or you can just search for this attack layer navigator and fill this out yourself. I will turn it over now back to clay. All right, excellent. Thank you. So here is an example of a Maltego graph. Maltego is a link analysis tool that we can use to pivot and to define additional data points, information and context. This example demonstrates how we pivot from an IP address to a file hash. So the file hash that I'm referring to here is the one that is tagged as sandstone malware. Just made that up. Malware has been attributed to a threat group. We see stardust kalima reference there, but it's also associated with another IP address, which has another website or URL associated with it. So all additional context. So now what? Well, the IP used in our intrusion can be associated to other pieces of malware so we can see that. So this should be investigated for additional evidence. The malware we pivot to or pivoted to in this example was not found in our environment. So it is possible that another adversary is using the same infrastructure. Right. So for the reverence is required in order to be able to identify that or apply some sort of level of confidence as well. So I actually added addition another piece of malware to demonstrate that there are two pieces of malware in this scenario now so it there can be different scenarios that come about but just wanted to highlight this other possibility where another piece of malware was identified. Using that IP address or that IP address was serving up multiple different pieces of malware there. And another one was identified, and it is attributed to a different threat actor. In this example, it's noted that the limestone malware is has been attributed to hidden cobra. So for our example and demonstration purposes for kill chain one. Two different threat groups using two different pieces of two pieces of malware have been associated with that with that IP address and each piece of malware is associated with the different threat group. Now one thing that is interesting is that hidden cobra and sardus kalima are are attributed to North Korea. So, we could say with high confidence that our intrusion is associated with North Korea. Now, for Magnus Tempest attribution is not one of our threat intelligence requirements, maybe it is for your organization. I would argue for most organizations that attribution shouldn't matter. What matters is the intrusion right, who cares, who did it, how will, how would knowing the adversary change anything you do, would it. I would argue that it wouldn't perhaps another discussion for another time, but since attribution is not in what one of our threat intelligence requirements, it's an interesting observation that we can make. And an interesting observation that we can include more an interesting assessment maybe that we can include in our CTI report. Yeah, it could be useful for other things as well but I would really demonstrate that Maltego can be used for for pivoting finding additional information and providing more context around an intrusion. And with that, I'll kick it over to Stephanie. Great. So, these last two sections will be about dissemination of the information and the feedback and evaluation. So dissemination here in this kill chain specifically since all of our teams were involved in the incident. They're already aware of the outcomes and aside from the report being generated and being delivered to our stakeholders. We don't have anyone else that we have to update about the incident right. There's no other dissemination required in another scenario if there was a team that wasn't involved and was not a stakeholder. So I want to think about how to distribute the information to them and what they need to know about the incident. So next we'll talk about here just an overview again of the stakeholders in this specific incident so we had or the specific kill chain. We also had the executives management it team and then members of our sock on the right. So next we'll talk about feedback and evaluation and a method for evaluating your CTI life cycle. So here during the planning and direction phase, you want to make sure you have defined documented and socialized processes for feedback. You don't want to be, you want everyone to know how to provide feedback. And you want a clearly defined process for this, you know, you want it to be documented so everyone is aware. And you want really ongoing feedback you want it to be readily available people to give feedback to you. And once you receive this feedback, you want to evaluate your processes so you want them to be complete, accurate, relevant and timely. So we'll talk about these in a little bit more depth so you want to complete. The CTI information intelligence provided to be complete. So, does it have enough information to generate a proper response. So how comprehensive is the intelligence are all of the data attributes present. Is there vulnerability analysis. Not really across an entire organization and doesn't look at like non cyber intelligence and other events for like a complete threat profile. So this comes back to like your intelligence requirements at the very beginning. Were you able to capture all of these and did you deliver. Was it accurate. So were there errors in your generated intelligence, you know what data sources, did you use where they accurate. Was this the most up to date information, or were there information changes along the way. And is it time bound is there like an expiration for this intelligence. Sometimes if you if you provide information about specific IOC's those might change very quickly. So it's important to note, if it's time bound and how long this will be accurate for. Okay, so now we'll talk about, is it relevant and is it timely. So your intelligence has to address the relevant threats inside your organization and be delivered in a way that allows for effective action, right so does it map back to your original intelligence requirements. So how do stakeholders submit requirements and provide feedback for more relevant intelligence. And is it timely has to be produced and delivered quickly. So it can be used fast enough to make a difference. So, how is it delivered to ensure quick consumption is it delivered by email, etc. How long between the discovery of a threat and notifying the stakeholders. So is this is this intelligence released to the stakeholders, as you go along and you learn more, or is it at the very end. So that's it for feedback and evaluation and I'll pass it back to Clay. Alright, thank you. Thank you, Stephanie. Yep, so here's some resources that were touched upon in the presentation. Thanks for watching. We joined the conversation on discord here. This is our discord. There's also the defcon discord that that folks should be in will be monitoring those channels as well. So please engage there. And wanted to call out that we, we did create a module one session, and that was released prior to defcon. So, if you're unsure about any of the content in this, in this module three, be sure to refer back to that that module one session that is available and up on YouTube. So, thanks again, everyone, and look forward to engaging in the conversation and see you in in future modules. Thank you.