WEBVTT 0:00:07.040000 --> 0:00:11.560000 So, as the title suggests, in this video, we're going to be understanding 0:00:11.560000 --> 0:00:17.360000 or taking a look at the process of analyzing IUCs and more specifically 0:00:17.360000 --> 0:00:22.240000 as part of the analysis, we're going to be exploring enrichment, right? 0:00:22.240000 --> 0:00:25.360000 So let's not waste any time. 0:00:25.360000 --> 0:00:27.620000 What is IUC analysis? 0:00:27.620000 --> 0:00:33.060000 In the previous video, we got an intro to IUCs, indicators of compromise, 0:00:33.060000 --> 0:00:36.740000 and we went through the various types or categories and then some common 0:00:36.740000 --> 0:00:46.920000 examples. And we also took a look at the process of IUC identification 0:00:46.920000 --> 0:00:48.460000 and what that entails. 0:00:48.460000 --> 0:00:53.660000 So, we can now move to the next logical step, which is IUC analysis, which 0:00:53.660000 --> 0:00:59.060000 is again something you may not really have heard of before as a process, 0:00:59.060000 --> 0:01:07.100000 but it's something that, again, is something that can be defined as analysis 0:01:07.100000 --> 0:01:15.980000 because of all the steps that are included as a subset of the analysis. 0:01:15.980000 --> 0:01:18.840000 And this will make sense in a second. 0:01:18.840000 --> 0:01:23.380000 So, IUC analysis is the process of investigating and understanding indicators 0:01:23.380000 --> 0:01:29.160000 of compromise, like suspicious IP addresses, file hashes or domains, in 0:01:29.160000 --> 0:01:32.400000 order to figure out if they're part of a cyber attack. 0:01:32.400000 --> 0:01:37.920000 So, essentially, what I call IUC analysis is the process of investigating, 0:01:37.920000 --> 0:01:42.760000 understanding indicators of compromise, but also validating them. 0:01:42.760000 --> 0:01:47.580000 So, the best way to understand IUC analysis is to think of it like being 0:01:47.580000 --> 0:01:49.300000 a digital detective, right? 0:01:49.300000 --> 0:01:54.820000 So, you find a clue, in this case, an IUC in an alert or log, right? 0:01:54.820000 --> 0:02:00.780000 And you look it up to see if it's known to be bad or involved in bad activity. 0:02:00.780000 --> 0:02:04.980000 And you check where it came from, who used it and what it tried to do. 0:02:04.980000 --> 0:02:07.780000 And you decide if it's dangerous and if action is needed. 0:02:07.780000 --> 0:02:11.020000 So, this is what IUC analysis is all about. 0:02:11.020000 --> 0:02:14.460000 And you'll understand where enrichment got, you know, where that comes 0:02:14.460000 --> 0:02:17.000000 into play with regards to analysis. 0:02:17.000000 --> 0:02:19.620000 So, let's get into IUC enrichment. 0:02:19.620000 --> 0:02:24.280000 So, IUC enrichment is the process of adding contextual information to 0:02:24.280000 --> 0:02:29.920000 raw indicators of compromise because indicators of compromise can be qualitatively 0:02:29.920000 --> 0:02:38.980000 raw, as it were, and enriched, and they're enriched through or through 0:02:38.980000 --> 0:02:43.640000 the process of adding contextual information to them, right? 0:02:43.640000 --> 0:02:49.260000 And you do this to make these indicators of compromise, these raw indicators 0:02:49.260000 --> 0:02:54.220000 of compromise more actionable, accurate and meaningful for the purposes 0:02:54.220000 --> 0:02:58.280000 of detection, triage, investigation, and of course response. 0:02:58.280000 --> 0:03:04.440000 So, while raw IUCs, like an IP or a file hash, and remember I mentioned 0:03:04.440000 --> 0:03:10.040000 this when we were getting into IUCs, I talked about how, you know, if 0:03:10.040000 --> 0:03:14.720000 you're new to IUCs and I tell you that an IP address is an indicator of 0:03:14.720000 --> 0:03:19.240000 compromise, you probably would have asked yourself, well, how is that 0:03:19.240000 --> 0:03:25.780000 indicative of, how is that an indicator of compromise or of any of anything 0:03:25.780000 --> 0:03:30.800000 suspicious? And I mentioned to you that you need to sort of analyze them 0:03:30.800000 --> 0:03:34.740000 more, and this is where enrichment comes into play. 0:03:34.740000 --> 0:03:39.160000 I mentioned I use the word analyze very importantly because enrichment 0:03:39.160000 --> 0:03:41.080000 is part of the analysis process. 0:03:41.080000 --> 0:03:46.080000 Hopefully, it's starting to come together in terms of you have IUCs. 0:03:46.080000 --> 0:03:52.160000 When we're talking about raw IUCs, they don't, you know, there's not really 0:03:52.160000 --> 0:03:57.660000 much information associated or attached to them to begin with. 0:03:57.660000 --> 0:04:03.820000 And you know, based on that, you know, beginner or if you look at it from, 0:04:03.820000 --> 0:04:09.420000 you know, from a very basic point of view, you probably arrive at the 0:04:09.420000 --> 0:04:12.340000 conclusion that that's not really an indicator of anything and you're 0:04:12.340000 --> 0:04:15.620000 right. And this is where the analysis comes into play, right? 0:04:15.620000 --> 0:04:21.460000 So you know about the types of the various types of IUCs as I covered 0:04:21.460000 --> 0:04:26.860000 in the previous video, and we mentioned the categories or network based 0:04:26.860000 --> 0:04:28.200000 IUCs, et cetera. 0:04:28.200000 --> 0:04:33.480000 So when you approach IUCs from that perspective, so let's say you find 0:04:33.480000 --> 0:04:41.400000 a log with an IP address, it could be, you know, a log pertinent to authentication 0:04:41.400000 --> 0:04:43.280000 or something like this. 0:04:43.280000 --> 0:04:45.300000 Not really important. 0:04:45.300000 --> 0:04:48.600000 What was the log is pertinent? 0:04:48.600000 --> 0:04:49.540000 Of course, it is important. 0:04:49.540000 --> 0:04:51.820000 That's the first part of enrichment. 0:04:51.820000 --> 0:04:55.460000 But the first thing you should be doing is saying, okay, that's a network 0:04:55.460000 --> 0:04:58.040000 based IUC from that point on. 0:04:58.040000 --> 0:05:02.940000 And the reason that classification is important is because it then tells 0:05:02.940000 --> 0:05:10.540000 you what tools or what you need to do to analyze that specific type of 0:05:10.540000 --> 0:05:15.100000 IUC. So if you don't categorize them correctly at that starting. 0:05:15.100000 --> 0:05:19.300000 So if you just go, oh, this is an IP address, you don't know what to do. 0:05:19.300000 --> 0:05:23.520000 But if you classify it and say, okay, that's a network based IUC, I don't 0:05:23.520000 --> 0:05:24.440000 know much about it. 0:05:24.440000 --> 0:05:27.900000 But just by virtue of the fact that I know that that's a network based 0:05:27.900000 --> 0:05:34.820000 IUC, you then know what to do next in terms of learning more about it. 0:05:34.820000 --> 0:05:38.560000 So if you're saying to yourself, well, I don't really know what to do 0:05:38.560000 --> 0:05:39.460000 next. Don't worry. 0:05:39.460000 --> 0:05:40.820000 That's what I want to cover. 0:05:40.820000 --> 0:05:42.940000 And that's what enrichment addresses. 0:05:42.940000 --> 0:05:49.680000 So while raw IOC is like an IP or file hash offers clues, enrichment answers 0:05:49.680000 --> 0:05:54.540000 critical questions like, what does this indicator represent in totality 0:05:54.540000 --> 0:05:59.380000 or holistically be is it known to be malicious? 0:05:59.380000 --> 0:06:04.280000 What threat actors or campaigns is it associated with, if any? 0:06:04.280000 --> 0:06:10.240000 And how urgent is the response based on the previous question? 0:06:10.240000 --> 0:06:13.240000 So hopefully it's starting to come together. 0:06:13.240000 --> 0:06:18.340000 Now, when we talk about the enrichment process, there's a couple of enrichment 0:06:18.340000 --> 0:06:21.300000 techniques that you need to be familiar with, right? 0:06:21.300000 --> 0:06:28.300000 The first is adding contextual data or contextualizing an IOC, right? 0:06:28.300000 --> 0:06:33.940000 So this technique, this type of IUC enrichment technique enhances the 0:06:33.940000 --> 0:06:40.220000 IOC with environmental and threat relevant information that helps analysts 0:06:40.220000 --> 0:06:41.540000 make better decisions. 0:06:41.540000 --> 0:06:43.640000 That's obviously implied. 0:06:43.640000 --> 0:06:47.560000 If you're enriching something, you know, if you're enriching your understanding 0:06:47.560000 --> 0:06:50.860000 of something, it helps you make better decisions with regards to your 0:06:50.860000 --> 0:06:53.840000 understanding of that thing, for example. 0:06:53.840000 --> 0:07:01.760000 So this table sort of outlines the various types of what you would call 0:07:01.760000 --> 0:07:06.280000 contextual enrichment when it comes to IOC. 0:07:06.280000 --> 0:07:11.340000 So the context type to the in the first column, you have geolocation ASN, 0:07:11.340000 --> 0:07:14.320000 who is threat actor association and then the purpose on the right. 0:07:14.320000 --> 0:07:19.020000 So when we talk about geolocation as a context type, this is where you 0:07:19.020000 --> 0:07:23.920000 identify the geographic origin of an IP address, for example, C2 traffic 0:07:23.920000 --> 0:07:26.480000 from a country with known threat activity. 0:07:26.480000 --> 0:07:30.000000 So if you remember what I said in the previous slide, when you start off, 0:07:30.000000 --> 0:07:38.060000 you find a log with a network traffic and you say, okay, this is a network 0:07:38.060000 --> 0:07:43.120000 based IOC, that then tells you what to do next based on the type of IOC 0:07:43.120000 --> 0:07:44.180000 you're dealing with. 0:07:44.180000 --> 0:07:48.260000 So if it's an IP, this is when you're talking about adding contextual 0:07:48.260000 --> 0:07:52.420000 data, you then start with geolocation, right? 0:07:52.420000 --> 0:07:57.060000 And you're trying to look for the geographic origin of the IP, which then 0:07:57.060000 --> 0:08:04.400000 tells you or probably tell you what you're dealing with. 0:08:04.400000 --> 0:08:07.200000 You probably need to investigate that a little bit more. 0:08:07.200000 --> 0:08:09.280000 You then have the ASN, right? 0:08:09.280000 --> 0:08:11.660000 So the autonomous system number. 0:08:11.660000 --> 0:08:16.180000 So you now check, you know, helps group IPs by ownership. 0:08:16.180000 --> 0:08:17.880000 That's what the purpose of ASN. 0:08:17.880000 --> 0:08:22.040000 So for example, a specific hosting provider or, you know, let's say cloud 0:08:22.040000 --> 0:08:29.360000 flare, when you host an EC2 instance and you assign a public IP, if you 0:08:29.360000 --> 0:08:33.800000 actually perform a look up on that IP, whatever that IP address is, I'm 0:08:33.800000 --> 0:08:39.060000 talking about the public IP address and you take a look at the IP ASN 0:08:39.060000 --> 0:08:46.080000 or the IP block ownership, you'll see that they all belong to AWS. 0:08:46.080000 --> 0:08:47.760000 So what is this useful for? 0:08:47.760000 --> 0:08:51.600000 It's useful for identifying clusters of infrastructure. 0:08:51.600000 --> 0:08:55.040000 Yeah, barely, it's self evident. 0:08:55.040000 --> 0:08:56.580000 Then you have who is information. 0:08:56.580000 --> 0:09:03.300000 So when you find a, this can also apply to IP addresses, but when you 0:09:03.300000 --> 0:09:10.820000 find a URL in a log, so indicative of compromise there, what do you do? 0:09:10.820000 --> 0:09:13.460000 Well, you perform who is look up, right? 0:09:13.460000 --> 0:09:16.120000 And what does this help with or what's the purpose of this? 0:09:16.120000 --> 0:09:20.080000 Well, it reveals the domain registration data like the owner date created 0:09:20.080000 --> 0:09:26.500000 contact info. So if you see a domain within a log and when your performer 0:09:26.500000 --> 0:09:30.300000 look up on that particular domain and you find it was registered within 0:09:30.300000 --> 0:09:35.840000 the last two weeks and it's quite an odd looking domain and it's registered, 0:09:35.840000 --> 0:09:39.440000 you know, to a particular individual, although that information can be 0:09:39.440000 --> 0:09:43.420000 hidden. You know, you're just trying to understand what you're dealing 0:09:43.420000 --> 0:09:55.340000 with or who this, what owns it, where it was registered, how new it is, 0:09:55.340000 --> 0:10:00.880000 etc. So red flags, as I just mentioned, I should have probably went through 0:10:00.880000 --> 0:10:04.200000 the point. It explains it a little bit better, but red flags include newly 0:10:04.200000 --> 0:10:07.940000 registered domains or privacy protected registrations. 0:10:07.940000 --> 0:10:13.340000 Now that's not always the case because you can always buy privacy protection 0:10:13.340000 --> 0:10:17.480000 for domains when you register them and that will obfuscate your personal 0:10:17.480000 --> 0:10:21.700000 or personally identifiable information with regards to, you know, the 0:10:21.700000 --> 0:10:24.520000 domain registrar. 0:10:24.520000 --> 0:10:27.400000 And then of course, the other context type is threat actor association 0:10:27.400000 --> 0:10:31.440000 or attribution. So you link the IOC to known threat actors or campaigns 0:10:31.440000 --> 0:10:34.600000 based on threat intelligence reporting. 0:10:34.600000 --> 0:10:38.800000 And this helps understand the likely TTPs and motivations, right? 0:10:38.800000 --> 0:10:41.760000 So this is adding contextual data. 0:10:41.760000 --> 0:10:45.560000 The other enrichment technique is leveraging threat intelligence sources 0:10:45.560000 --> 0:10:50.200000 and will be covering threat intelligence and threat hunting in detail 0:10:50.200000 --> 0:10:53.860000 in its own course within this learning path. 0:10:53.860000 --> 0:10:58.480000 And the only reason I'm doing so is because threat intel plays a huge 0:10:58.480000 --> 0:11:05.060000 part in, you know, organizations security and likewise threat hunting 0:11:05.060000 --> 0:11:06.860000 and it needs its own course. 0:11:06.860000 --> 0:11:09.840000 But it's all going to be in the context of instant response. 0:11:09.840000 --> 0:11:12.400000 In any case, leveraging threat intelligence sources. 0:11:12.400000 --> 0:11:16.920000 So external and internal threat intelligence helps validate and enrich 0:11:16.920000 --> 0:11:20.800000 indicators with global and organizational insight. 0:11:20.800000 --> 0:11:24.940000 So in this case, when we're talking about the threat intelligence sources, 0:11:24.940000 --> 0:11:29.400000 we have external threat feeds, sandbox results, passive DNS and passive 0:11:29.400000 --> 0:11:34.660000 SSL information and internal reputation databases. 0:11:34.660000 --> 0:11:38.340000 So starting with external threat feeds, what's the functionality here 0:11:38.340000 --> 0:11:41.180000 or relevance to IOC enrichment? 0:11:41.180000 --> 0:11:48.260000 Well, sources like virus total, IP abuse, IPDB, Alien Vault OTX, very 0:11:48.260000 --> 0:11:54.140000 popular, recorded future or commercial TI vendors provide reputation scores, 0:11:54.140000 --> 0:11:56.540000 tagging and relationships. 0:11:56.540000 --> 0:12:02.760000 In the case of sandbox results, you know, dynamic analysis using platforms 0:12:02.760000 --> 0:12:08.980000 or tools like any dot run, very popular, I use it myself, albeit for analyzing 0:12:08.980000 --> 0:12:10.900000 malicious documents. 0:12:10.900000 --> 0:12:15.300000 Which will also be covering in the digital forensics, for instance, response 0:12:15.300000 --> 0:12:16.900000 course within this learning path. 0:12:16.900000 --> 0:12:20.380000 But, you know, I'm just trying to let you know we'll be covering a lot 0:12:20.380000 --> 0:12:24.540000 of this stuff. In any case, you know, dynamic analysis using any run, 0:12:24.540000 --> 0:12:29.800000 for example, or hybrid analysis, simulates execution of files or malware 0:12:29.800000 --> 0:12:34.240000 or URLs in order for you to observe the behavior and extract secondary 0:12:34.240000 --> 0:12:38.760000 IOCs, which I'll touch on in this video. 0:12:38.760000 --> 0:12:41.780000 You then have passive DNS and passive SSL. 0:12:41.780000 --> 0:12:45.440000 So, you know, this is where you observe historic domain IP bearings and 0:12:45.440000 --> 0:12:49.980000 certificate usage to track infrastructure reuse, something that's very 0:12:49.980000 --> 0:12:52.880000 important. And then internal reputation databases. 0:12:52.880000 --> 0:12:58.260000 So you correlate new IOCs with past incidents, you hunt results, threat 0:12:58.260000 --> 0:13:00.080000 hunting or false positive reports. 0:13:00.080000 --> 0:13:03.940000 And this is very critical for environment specific relevance. 0:13:03.940000 --> 0:13:09.020000 So this is, you know, using internal intelligence or internal reputation 0:13:09.020000 --> 0:13:15.800000 databases. And then the other enrichment technique is, I wouldn't say 0:13:15.800000 --> 0:13:20.020000 it's a technique, but, you know, it's enrichment for enhanced decision 0:13:20.020000 --> 0:13:27.320000 making. So enrichment or enriched IOCs are not just informative, they're 0:13:27.320000 --> 0:13:28.220000 strategic, right? 0:13:28.220000 --> 0:13:31.220000 They feed directly into key decision making areas. 0:13:31.220000 --> 0:13:34.100000 And what are these key decision making areas? 0:13:34.100000 --> 0:13:36.360000 Or what are the objectives here? 0:13:36.360000 --> 0:13:40.800000 Well, we have determining severity, defining the scope, prioritizing response 0:13:40.800000 --> 0:13:42.620000 and triage accuracy. 0:13:42.620000 --> 0:13:48.900000 So this sort of relates or corresponds to why this is important or why 0:13:48.900000 --> 0:13:52.480000 IOC enrichment is relevant to you as an instant responder. 0:13:52.480000 --> 0:13:57.000000 So when we talk about determining severity as an objective and how enrichment 0:13:57.000000 --> 0:14:02.560000 helps, an IOC linked to a non ransomware infrastructure increases the 0:14:02.560000 --> 0:14:03.960000 criticality of an alert. 0:14:03.960000 --> 0:14:06.520000 That's self evidently true, right? 0:14:06.520000 --> 0:14:11.020000 And then when it comes down to defining scope, context such as or like, 0:14:11.020000 --> 0:14:14.780000 you know, multiple host observations, lateral movement evidence or multiple 0:14:14.780000 --> 0:14:18.420000 users interacting with an IOC expands the scope. 0:14:18.420000 --> 0:14:23.800000 So if you see the IOC replicated across different systems or just limited 0:14:23.800000 --> 0:14:28.780000 to one system or one host as it were within a network, it tells you what, 0:14:28.780000 --> 0:14:31.260000 you know, the scope of what you're dealing with. 0:14:31.260000 --> 0:14:35.820000 So that again is also a self explanatory to a certain degree. 0:14:35.820000 --> 0:14:37.740000 And then prioritizing response. 0:14:37.740000 --> 0:14:40.340000 So how does enrichment help here? 0:14:40.340000 --> 0:14:45.020000 Well, IOCs associated with low prevalence, high impact threats like, you 0:14:45.020000 --> 0:14:50.120000 know, data exaltration or hands on keyboard attacks, warrants, faster 0:14:50.120000 --> 0:14:54.220000 containment and triage accuracy. 0:14:54.220000 --> 0:14:55.660000 How does enrichment help here? 0:14:55.660000 --> 0:15:00.300000 Well, it helps tier one analysts quickly identify false positives or escalate 0:15:00.300000 --> 0:15:06.180000 real threats with confidence because again, without IOC enrichment, if 0:15:06.180000 --> 0:15:11.600000 a tier one analyst did not factor that in and they found an IP address, 0:15:11.600000 --> 0:15:16.680000 you know, and they sort of arrived at the, they arrived at the assumption 0:15:16.680000 --> 0:15:24.520000 that this is malicious or is indicated, it's indicative of malicious activity 0:15:24.520000 --> 0:15:27.740000 and they choose to escalate to the instant responder and did not perform 0:15:27.740000 --> 0:15:33.100000 IOC enrichment in the form of performing a lookup on that IP address. 0:15:33.100000 --> 0:15:36.640000 Then, you know, that's going to lead to false positives because then the 0:15:36.640000 --> 0:15:41.400000 instant responder would perform IOC enrichment and they find out that 0:15:41.400000 --> 0:15:45.440000 that IP is not really malicious, nor has it been associated with any malicious 0:15:45.440000 --> 0:15:48.020000 activity, known malicious activity. 0:15:48.020000 --> 0:15:50.980000 Of course, I'm not saying that, you know, you should die by that sword 0:15:50.980000 --> 0:15:56.260000 because again, attackers will not be using will not always be using known 0:15:56.260000 --> 0:16:02.040000 indicators of compromise or their activity will not elicit known indicators 0:16:02.040000 --> 0:16:07.400000 of compromise. But the bottom line is that performing IOC enrichment really, 0:16:07.400000 --> 0:16:12.960000 really helps the with triage accuracy and for reasons I've just explained 0:16:12.960000 --> 0:16:21.800000 here. So, now that you understand the IOC analysis process as well as 0:16:21.800000 --> 0:16:31.620000 IOC enrichment, you may as well as instant responders, could you please 0:16:31.620000 --> 0:16:39.680000 tell me who is responsible for what with regards to IOCs or what do I 0:16:39.680000 --> 0:16:44.260000 as an incident responder need to know with regards to IOCs or what should 0:16:44.260000 --> 0:16:48.360000 I be able to do with regards to indicators of compromise and that's what 0:16:48.360000 --> 0:16:49.580000 I seek to address here. 0:16:49.580000 --> 0:16:54.340000 So, the responsibilities in IOC handling or handling IOCs. 0:16:54.340000 --> 0:16:57.740000 So, let's start off with the tier one analyst responsibilities in IOC 0:16:57.740000 --> 0:17:02.160000 handling. So, the tier one sock analysts on the front lines of the instant 0:17:02.160000 --> 0:17:06.260000 response process in terms of detection triage, etc. 0:17:06.260000 --> 0:17:10.660000 And their role is, as I said to triage alerts identify threats early and 0:17:10.660000 --> 0:17:14.220000 determine if further action is needed, especially using IOCs and their 0:17:14.220000 --> 0:17:20.000000 key responsibilities are with regards to IOC handling are alert triage 0:17:20.000000 --> 0:17:21.380000 and IOC matching. 0:17:21.380000 --> 0:17:26.200000 So, analysts review alerts generated by tools like SEEMS and EDR platforms. 0:17:26.200000 --> 0:17:31.120000 They look for IOCs, so suspicious IPs, domains, file ashes, etc. 0:17:31.120000 --> 0:17:33.000000 in the alert data. 0:17:33.000000 --> 0:17:36.960000 And these IOCs are matched against known bad lists. 0:17:36.960000 --> 0:17:38.860000 This is when Richmond comes into play. 0:17:38.860000 --> 0:17:42.260000 So, think of internal block lists or threat intelligence feeds. 0:17:42.260000 --> 0:17:48.540000 And the goal here is to identify real threats quickly through enrichment 0:17:48.540000 --> 0:17:50.380000 and discard the false positives. 0:17:50.380000 --> 0:18:01.000000 So, this is when I referenced over here the use of value of enrichment 0:18:01.000000 --> 0:18:05.000000 for an hands decision make and I mentioned triage accuracy. 0:18:05.000000 --> 0:18:10.620000 That's what I mean there with regards to the key responsibilities of tier 0:18:10.620000 --> 0:18:14.860000 one analyst with regard to IOC handling. 0:18:14.860000 --> 0:18:19.220000 In addition to that, they also responsible. 0:18:19.220000 --> 0:18:20.920000 This is not always the case. 0:18:20.920000 --> 0:18:27.720000 It varies by organization in terms of the degree or the extent to which 0:18:27.720000 --> 0:18:31.160000 this is done. And that is basic IOC enrichment. 0:18:31.160000 --> 0:18:36.100000 So, tier one analysts perform lightweight research to add context to the 0:18:36.100000 --> 0:18:41.700000 IOCs. Now, you're starting to understand contextual enrichment as a technique 0:18:41.700000 --> 0:18:44.700000 when we're talking about IOC enrichment early on. 0:18:44.700000 --> 0:18:49.300000 In any case, this would involve the use of virus total to check a file 0:18:49.300000 --> 0:18:53.360000 hash or URL and see if it's flagged by antivirus vendors as malicious 0:18:53.360000 --> 0:18:59.120000 to look up GYP data to identify suspicious IP origins. 0:18:59.120000 --> 0:19:01.860000 Like, for example, a login from North Korea deadringer. 0:19:01.860000 --> 0:19:07.700000 That's definitely something that should be causing, you know, should be 0:19:07.700000 --> 0:19:12.500000 escalated. Another would be, you know, using who is to check domain registration 0:19:12.500000 --> 0:19:16.920000 info. For example, newly registered or anonymized domains. 0:19:16.920000 --> 0:19:23.740000 And this enrichment, you know, basic IOC enrichment helps answer the question, 0:19:23.740000 --> 0:19:27.720000 is this IOC really malicious or is it just unusual? 0:19:27.720000 --> 0:19:31.780000 And that's a very, very important point because what you would consider 0:19:31.780000 --> 0:19:37.260000 or a SOC tier one analyst would consider, you know, they would typically 0:19:37.260000 --> 0:19:41.600000 consider something either malicious or unusual. 0:19:41.600000 --> 0:19:46.740000 Now, of course, this type of enrichment, basic enrichment will help you 0:19:46.740000 --> 0:19:48.040000 answer that question. 0:19:48.040000 --> 0:19:51.120000 It'll tell you whether it's really malicious and whether it should be 0:19:51.120000 --> 0:19:58.000000 investigated further by the instant responder or it's just unusual, right? 0:19:58.000000 --> 0:20:03.220000 So if you perform, you know, GYP lookups and you see, it's not really, 0:20:03.220000 --> 0:20:08.700000 the IP address is not from a suspicion suspicious region, geographical 0:20:08.700000 --> 0:20:16.760000 region. OK, so it looks from, let's say, North America or Europe and doesn't 0:20:16.760000 --> 0:20:18.280000 really look suspicious. 0:20:18.280000 --> 0:20:23.940000 If in the case of a domain, let's say it was registered one year ago and 0:20:23.940000 --> 0:20:27.680000 it's for, you know, when you visit the website, it looks like a legitimate 0:20:27.680000 --> 0:20:31.360000 startup, you know, the legitimate website for a startup. 0:20:31.360000 --> 0:20:36.820000 It starts moving from something that looked very suspicious or malicious 0:20:36.820000 --> 0:20:38.820000 to something that just looks unusual. 0:20:38.820000 --> 0:20:42.580000 And that doesn't mean it doesn't warrant further investigation. 0:20:42.580000 --> 0:20:50.220000 Basic IUC enrichment just it just assists the tier one analyst in that 0:20:50.220000 --> 0:20:57.220000 understanding the actual validity of an IUC with regards to whether or 0:20:57.220000 --> 0:21:01.320000 not it is malicious or requires further analysis. 0:21:01.320000 --> 0:21:07.680000 And then we also have escalation decision, the escalation decision making. 0:21:07.680000 --> 0:21:12.580000 So based on the analysis and enrichment already performed, tier one analysts 0:21:12.580000 --> 0:21:16.880000 decide whether to escalate to tier two or the instant responder or the 0:21:16.880000 --> 0:21:21.780000 instant response team for deep investigation to close the alert if it's 0:21:21.780000 --> 0:21:25.960000 a false positive or non malicious and not have you do the IUC enrichment 0:21:25.960000 --> 0:21:27.760000 as the instant responder. 0:21:27.760000 --> 0:21:32.460000 That's not to say that you can't or you you can't validate the IUC enrichment 0:21:32.460000 --> 0:21:34.240000 that was performed. 0:21:34.240000 --> 0:21:40.220000 It just means that ideally the tier one analyst should be performing IUC 0:21:40.220000 --> 0:21:45.300000 enrichment for the purpose of understanding whether or not something really 0:21:45.300000 --> 0:21:47.020000 is malicious or not. 0:21:47.020000 --> 0:21:51.680000 Now of course they can't arrive at that determination 100% of the time. 0:21:51.680000 --> 0:21:57.000000 And in cases where additional investigation is warranted, then definitely 0:21:57.000000 --> 0:22:01.700000 tier one analyst should not hesitate in escalating it. 0:22:01.700000 --> 0:22:06.160000 And of course you would also put it through the escalation criteria to 0:22:06.160000 --> 0:22:12.560000 see whether this type of IUC has been part of other false positives. 0:22:12.560000 --> 0:22:15.560000 If it hasn't, then it's probably something that should be investigated. 0:22:15.560000 --> 0:22:20.460000 So you can see all of this is sort of tied is tied together. 0:22:20.460000 --> 0:22:25.140000 In any case, finally decisions are based on evidence context and standard 0:22:25.140000 --> 0:22:30.780000 operating procedures, which is again something that should be fairly obvious. 0:22:30.780000 --> 0:22:31.920000 All right, so moving on. 0:22:31.920000 --> 0:22:36.660000 What is now what are the responsibilities in IUC handling with regard 0:22:36.660000 --> 0:22:41.740000 to tier two sock analysts or incident responders? 0:22:41.740000 --> 0:22:46.660000 So firstly, incident responders operate at a deeper investigative layer 0:22:46.660000 --> 0:22:54.680000 in the SOC assuming that we're using the model where a SOC comprises of 0:22:54.680000 --> 0:22:56.460000 the tier one analyst and a tier two analyst. 0:22:56.460000 --> 0:22:58.700000 Who is defined as an incident responder. 0:22:58.700000 --> 0:23:03.420000 There may be other cases where there's a SOC and a separate siloed incident 0:23:03.420000 --> 0:23:07.900000 response team that's just responsible for instant response, right? 0:23:07.900000 --> 0:23:12.700000 But the bottom line is that instant responders, as you already know, operated 0:23:12.700000 --> 0:23:15.000000 a deeper investigative layer. 0:23:15.000000 --> 0:23:18.880000 And when tier one or two analysts escalate an alert, the incident responders, 0:23:18.880000 --> 0:23:22.600000 you know, depending on how a SOC is structured, a tier two analyst may 0:23:22.600000 --> 0:23:26.260000 not be an incident responder, although in most cases, they are considered 0:23:26.260000 --> 0:23:27.700000 an incident responder. 0:23:27.700000 --> 0:23:31.460000 But the bottom line is let's say when a tier one analyst escalates an 0:23:31.460000 --> 0:23:36.400000 alert, the incident responder or responders step in to determine the full 0:23:36.400000 --> 0:23:40.020000 scope of the threat, contain it and enhance future detection often using 0:23:40.020000 --> 0:23:47.620000 advanced IOC, I wouldn't say IOC techniques, IOC enrichment techniques. 0:23:47.620000 --> 0:23:54.640000 So let's talk or let's take a look at some of what an incident responder 0:23:54.640000 --> 0:23:57.700000 would be doing with regard to IOC handling. 0:23:57.700000 --> 0:24:01.060000 So firstly, we have advanced IOC correlation and pivoting. 0:24:01.060000 --> 0:24:04.540000 So we have concepts like link analysis and pivoting. 0:24:04.540000 --> 0:24:07.580000 So when we talk about link analysis, what does this mean? 0:24:07.580000 --> 0:24:12.080000 This is where the instant responder is mapping connections between domains, 0:24:12.080000 --> 0:24:17.260000 IPs and hashes to uncover infrastructure or attacker behavior patterns. 0:24:17.260000 --> 0:24:26.260000 So they're sort of going a step further than the to sort of improve or 0:24:26.260000 --> 0:24:35.020000 further enrich the IOCs or to correlate the IOCs that the IOC enrichment 0:24:35.020000 --> 0:24:46.120000 done by the tier one analysts, they're now or augmented IOC analysis for 0:24:46.120000 --> 0:24:53.000000 the goal of link analysis, which is really correlation for all intents 0:24:53.000000 --> 0:24:57.900000 and purposes. But then we have pivoting, which is quite common where you 0:24:57.900000 --> 0:25:03.640000 start from a known IOC like a file hash and then you search across systems 0:25:03.640000 --> 0:25:10.700000 to identify. So let's say you have a known IOC, no matter whether it was 0:25:10.700000 --> 0:25:15.940000 given to you by the OITO's escalated to in the form of a case by the tier 0:25:15.940000 --> 0:25:19.460000 one analyst or it's something that you're doing under the guise of threat 0:25:19.460000 --> 0:25:24.280000 hunting, what you can then do or what incident responders usually do to 0:25:24.280000 --> 0:25:30.540000 identify the scope of the, you know, to identify scope in the event, you 0:25:30.540000 --> 0:25:37.580000 know, this IOC was actually detected within the environment, you know, 0:25:37.580000 --> 0:25:44.460000 to identify the scope by, you know, essentially searching using that IOC 0:25:44.460000 --> 0:25:48.760000 in this case, like a file ash searching across multiple systems to identify 0:25:48.760000 --> 0:25:55.260000 whether additional systems were infected, identify, you know, activity 0:25:55.260000 --> 0:25:59.080000 like lateral movement and of course, commanded controlled relationships. 0:25:59.080000 --> 0:26:03.280000 And the key point here is that this helps instant responders uncover the 0:26:03.280000 --> 0:26:08.960000 full kill chain and eliminate blind spots. 0:26:08.960000 --> 0:26:13.140000 You also have the use of threat hunting platforms and malware sandboxes. 0:26:13.140000 --> 0:26:18.420000 So in the case of threat hunting platforms, these allow proactive search 0:26:18.420000 --> 0:26:23.020000 for threats across large data sets using behavioral logic and IOC matching. 0:26:23.020000 --> 0:26:27.020000 In the case of malware sandboxes, instant responders, you know, typically 0:26:27.020000 --> 0:26:30.740000 execute suspicious files in isolated environments to observe behaviors. 0:26:30.740000 --> 0:26:35.100000 And this is the key point extract secondary IOCs and validate payload 0:26:35.100000 --> 0:26:42.620000 functionality. So again, answering your question about what you are responsible 0:26:42.620000 --> 0:26:47.060000 for doing or what you should know with regards to IOC handling as an instant 0:26:47.060000 --> 0:26:53.960000 responder, this I'm sort of outlining where they come into play and the 0:26:53.960000 --> 0:26:59.740000 additional enrichment that you will be performing in this case, you know, 0:26:59.740000 --> 0:27:03.520000 in the case of malware sandboxing or malware analysis, extracting things 0:27:03.520000 --> 0:27:07.880000 like secondary IOCs and validating payload functionality. 0:27:07.880000 --> 0:27:12.520000 But then more importantly, what your I wouldn't say 100% going to be responsible 0:27:12.520000 --> 0:27:16.680000 for doing, it all, you know, depends on how the organization is set up 0:27:16.680000 --> 0:27:19.160000 is generating new IOCs. 0:27:19.160000 --> 0:27:26.880000 So from investigations, instant responders will often discover new IOCs 0:27:26.880000 --> 0:27:33.820000 such as additional domains hashes or URLs used in the campaign, behavioral 0:27:33.820000 --> 0:27:42.340000 indicators like specific registry changes or process trees and infrastructure 0:27:42.340000 --> 0:27:46.760000 reuse patterns. And then these are then fed back into detection logic. 0:27:46.760000 --> 0:27:51.960000 So think of, you know, examples would be seam rules, EDR alerts, firewall 0:27:51.960000 --> 0:27:55.180000 blocks, etc. They're shared with threat intelligence teams. 0:27:55.180000 --> 0:27:59.700000 If there is a threat intelligence team or the SOC team, you know, detection 0:27:59.700000 --> 0:28:05.200000 engineering team in order to enrich organization wide defenses. 0:28:05.200000 --> 0:28:10.420000 And these are then also used to fine tune alerting and reduce false positives 0:28:10.420000 --> 0:28:15.340000 in the future. So hopefully that answered your question. 0:28:15.340000 --> 0:28:22.200000 And now that you sort of understand the, you know, what IOCs are, the 0:28:22.200000 --> 0:28:27.520000 identification process, which we took a look at in a practical sense early 0:28:27.520000 --> 0:28:30.480000 on in this course, when we're using elk. 0:28:30.480000 --> 0:28:35.340000 And now we've taken a look at the IOC analysis and enrichment process, 0:28:35.340000 --> 0:28:40.720000 as well as what you are responsible for doing or what your involvement 0:28:40.720000 --> 0:28:44.380000 will be with regard to IOCs. 0:28:44.380000 --> 0:28:50.800000 That brings us to the end, the formally the end of the triage and escalation 0:28:50.800000 --> 0:28:57.820000 section of this course, which now means we get to the real stuff, which 0:28:57.820000 --> 0:29:00.800000 is what you are going to be responsible for doing. 0:29:00.800000 --> 0:29:07.480000 Or we're now getting to the point where the SOC tier one analyst reaches 0:29:07.480000 --> 0:29:12.560000 out to you or escalates an incident to you, the instant responder for 0:29:12.560000 --> 0:29:17.760000 analysis and depending on your rules and responsibilities, containment, 0:29:17.760000 --> 0:29:22.800000 eradication, recovery is something that's usually done or handled by the 0:29:22.800000 --> 0:29:26.580000 infrastructure teams for obvious reasons. 0:29:26.580000 --> 0:29:30.120000 But with that being said, that's going to be it for this video. 0:29:30.120000 --> 0:29:32.260000 And I will be seeing you in the next video.