 Hello, welcome to Blue Team Village. We are so happy to see you tuning in. I'm excited and pumped to be part of BTV as this is my first time at BTV. Thanks for all the BTV team for making this happen and providing the feedback on the stock. That said, welcome to my talk. This talk is about hunting adversary schedule. Once an adversary gained a foothold, they typically would like to keep their access. This is called persistence and those who you speak mitre, it's called TA003. We will take a look at one such persistence technique or method called schedule task. Schedule task is one of the most observed techniques across three different mitre tactics according to Mandiant Trends 2022 report. Please go check that out. It's a pretty interesting report that you can find. We will focus mostly on this, on threat hunting for the stock and how to perform it as well. Those schedule tasks is one of the 385 sub-techniques that mentioned in mitre. You can follow the process discussed here for any of them. Before we move further, a little bit about myself. My name is Sai Mollike and I go by Cyberhawk too. I'm an avid lover of death. That is detection, engineering and threat hunting or the actual one. Currently I work as a socket for a company called SISIV, recently acquired by Fourscout. Apart from work, I love to travel, especially road trips. I volunteered for any security conferences and nonprofit organizations focusing on cyber and its journey. So if you have anything, I'd love to be part of it. Last but not least, I'm a student of everything. So if you want to teach me something, I'm all for it. Enough about me. Let's see what we have on the schedule today. We'll go over what schedule task is and its basics. We will see quirks and features of threat hunting, process of data gathering, and getting to know it. We'll see detection engineering, not all portions of it, just the basics or how to proceed it with the threat hunting. Finally, we will recap everything together, what we learned together, right? Perfect. A very important note before we dive deep into the weeds is note-taking. I know it sounds boring for some, but if you are anything like me, I don't remember what I did 15 minutes before when I'm into a case of any kind of data. And sometimes you will have this crazy thoughts and ideas on how to progress on another investigation when you're doing an investigation for something else. If you don't jog it down, you'll lose it, right? Finally, your notes should be your guide and for others who want to follow or reduce your steps. So be sure to take notes while we are going at and I'll mention it whenever possible. Good. Let's get to it. Schedule task. This is the definition Microsoft gave to schedule task on one of its stocks. It says schedule task is basically a code unit that runs logic in a background session at a specific time. Basically, you want to do something in the future or just one time, you can use schedule task to do it, but it's more than that. Schedule task help operating system programs to run at a defined time. It helps administrators to take action when a certain event happens. It helps update your anti-virus software at a defined interval. You get the idea, right? We'll go over some of the main components that make schedule task at your task. Among them, the first one is triggers. So we will see these components in terms of what is necessary for us. If you are more interested in it, you can go ahead and look at Microsoft docs. They do a good job in documenting most of their products and services how they do it. So triggers. Triggers is one of the component of schedule task which starts a schedule task. It answers when a certain indicator or indicator submit. Like I want to schedule a task or start a task every day at 9 a.m. That's your trigger. Then actions. This is the main thing that be as a threat hunter or your detection engineering folks or forensics is interested in because it answers when or sorry, it answers what a task is actually doing. For example, a program will execute when the about trigger is met. That program is what? Principles. This answers who is allowed to run the task. The other components are settings which answers where the task should look if there is any error. There is a detailed documentation on these components. If you check the Microsoft doc. And then we will have other two things called registration information and data. Answers how to look for data related to schedule tasks. Like there is a help information for schedule task or metadata info. You can find all those things in these two components. We will see how they will help us and we will refer back if necessary. So why are schedule tasks important, right? After successfully getting their foothold into their desired enterprise, do you think an adversary will want to lose their access or afford to lose their access because they accidentally control seeing their terminal? No, right? They want to keep access as long as possible or they want to keep their access to figure it out what to do with it or until they achieve their objectives. So it is also interesting especially for schedule tasks because it can be used in different stages of attacker lifecycle like persistence, privilege escalation and execution. But in this talk we will only talk about persistence. And who can create schedule tasks? Administrators or members in the administers group can create schedule tasks and also administers can give certain permissions for users in order for them to view or perform actions on schedule tasks. Okay, that's all good. Finally, we came here. We come to the topic we came here for. Threat hunting. But let's see what it is. Threat hunting is a process of being proactive to unveil unknown knowns and unknown unknowns to better our security posture. The main keywords are process because it is not set and done but rather a continuous thing. It is proactive as we are not working for something to happen but taking charge before it happens. Unknown knowns and unknown unknowns are a topic on its own but in a nutshell there are things we don't know and we want to know. We are doing all these things to better our security posture. This is a process but what is it? What is the process? This is the process we are talking about or we are following in this. This is not the only one but this is the one we are following today. First, we will create our hypothesis then we will find what data we need and what artifacts are related to our hypothesis. Then we need to know what we are working with exactly familiarizing ourselves with the data. From it, we will create queries to search for the data we gathered and familiarized with. Finally, interpreting the results and documenting it all. You can follow this process with detection engineering too but we will not go there yet but this is the process that we can follow. But there's a lot to unveil here. Let's break it down by each component. First thing is hypothesis. A possible or one of the definitions I found are pretty interesting is this. You can read the hypothesis but the main things are research interest, most important questions and decision because in order to be proactive we need to know what our interests are. What questions we need to ask to create a structure to our hunt. And lastly, decision because we need to know what we will do with it. After all this hunting and whatever came out of it what we will do with it. That's the decision process. In threat hunting we will typically have broad hypothesis and narrow hypothesis. That's not a law or you need to follow but it gives a kind of structure, possible structure to your hunts. Broad hypothesis is just an overall statement which can serve us to start a whole lot of hunts. Like our broad hypothesis could be adversaries use persistence mechanisms to stay connected. As you see it is broad and can lead to n number of things. You can use this broad hypothesis to schedule multiple hunts. The reason it's broad is it's just give you a glimpse of what you want but not exactly how you can do it or what detailed what information. The narrow hypothesis. For narrow hypothesis is specific applicable and actionable today. To form the narrow hypothesis we will answer some questions from one of Pluck's talk on Silver Sparrow in Shellcon 2021. If you didn't check that talk please go ahead. It has awesome information. Not only just the Silver Sparrow but the threatening process itself. We'll answer some of the questions from it, right? The first question is who? Who are we trying to hunt? What we want to hunt? And why we are doing all this? Where answers what data we want to hunt for? When is the timeframe related to the hunts? Every hunt should have a timeframe. So that's the when portion of it. And how is, how are we querying the data in our sim or analytical platform and how we want the platform to present the data to us? So let's fill them up. We want to hunt for adversaries. You can add insider threats to it if you want to include that in your hunts. We want to hunt for specifically schedule tasks. We would like to check this data for endpoints because that's one of the data points you can check for schedule tasks. We are doing this to unveil persistence mechanisms achieved by schedule tasks. And if you fill them all of them we can find this. Here we are saying adversaries might create or change schedule tasks on local or remote endpoints using QV or command line tools to execute additional or new executables files for maintaining persistence in our environment. And we are doing for as long as the data exists in our analytical platform and we are using some of the mechanisms like searching, grouping and stacking. But as you see, this is very specific. We can hunt for this today and our hypothesis will guide us through what we will search for in our analytical platform. Great. We have our broad and narrow hypothesis but what we can do with it, where we will use it. I like this meme a lot because most of the threat hunting is about pre-hunt preparation. If you remember our threat hunting process this is our second step, data gathering and what artifacts are related to what portion of it. If you are performing threat hunts most of your time will be going at this portion of it because this will define what you can do in the next sections. So let's get that data. Here when you say data, it's data coming from our point products or different mechanisms where you can gather or achieve the data in this case endpoint. For things we don't know, we will Google it. The first thing I Google is MITRE schedule tasks. MITRE is our dear friends where they have a beautiful website where they document most of the techniques, sub-techniques I've spoken about before. So when I Google this, the first link came out to be MITRE, ATT&CK MITRE Enterprise techniques and then when you go there, check at the detections portion of it. Under it, we can find data related to scheduled tasks. So this is specific to techniques so each taking will have the section. So when I go there, this is important to see how to interpret it is data source is what data you are collecting or you can search for. And detects is some of the artifacts they have observed using first schedule task which was used in attacks in the past. So we will take a note of all this. So first data is command, file, process, schedule job, lack of data is also important to us. We will discuss that in the coming slides but please take a note of all this data sources. We will check from the bottom, the schedule job, schedule job creation in specific. In that we will see some of the event IDs like specifically event ID 4698. Okay, so we will start with that event ID. Let's check that in Google again. Here I'm saying I want schedule task event IDs but I want only from Microsoft sites. That's the site notation. When I do it, the first thing came from Microsoft documentation and when I went in there, you can search for scheduled task in the left because it has all the events necessary and we will see all these events that are produced by or when action is performed on schedule task. Here you see 4698S, S is security channel. So one thing is event IDs are specific, are unique to a channel but not unique overall. Okay, so let's take a note of all this, like 4698, 4699 and everything, perfect. And we go back to MITRE again. In the same section, I see another one, Microsoft Windows Task Eduler operational. This one is related to a specific channel which has all the information related to schedule tasks. But if you read on it, it says enable the channel. That means in my mind, it says it's not enabled by default. So we will check what if it is enabled or not but we will take a note of that particular channel too. The second thing we will see is the file modifications, specifically file creation events. In this, it says it will be done in the system that you do tasks folder, which whichever is not related to a software or path cycle or et cetera. So we will search for it. But unlike before, we will search for Sysmon data, because why not? Because that is being rolled out in current enterprises as a cheap version of EDR sorts. But we will search for Sysmon data. When I search for file creation Sysmon, I have seen that event ID 11 is related to it. You can see some description related to the event. And also from MITRE and some blogs, we see that they happen in tasks folder and under svchost.exe process specifically. Okay, sure, we will take a note of it. Again, we go back to MITRE. We can see other things like command execution and process creations. For command executions, there are several types you can do it. Scheduled SES tasks, add.exe, PowerShell, WMI, and many more. So I will take a note of that too, because I want to search for this as this is one of the data points that I want to search for. In MITRE, there is an interesting section called procedure examples. This is interesting because here is where MITRE documents all the previous attacks that had happened using schedule tasks, or where schedule task is used in such attacks. Okay, so while searching for one of those blogs, I have seen that there is a new data point. That data point is registry keys. So it says that registry keys are also important in searching for schedule tasks, specifically registry events 12, 13, 14, according to Sysmon, and some of the registry, like create key, delete key and search. If you ever perform registry analysis and or check the registry, it is messy and ugly. But it would be a lot of fun if you are into that, sirs. I'll show you why. Here. We will just check what we want. I know this is scary, but we will just check only the things that we want for the registry. So if you go to the registry path mentioned about specifically till the tree portion of it, you can see all the schedule tasks that are there. These, some of the schedule tasks are under Microsoft, which are operating system specific. And the task which is highlighted here, the daily task is the name of the sample schedule task that we created. In this, there are many four subkeys. The interesting words are ID and SD. ID is a gibric, Google, that is unique to our schedule task. Here, ID is correlated with the daily task name of it. And SD is where our principle or security context under which schedule task is created. SD is also important because it acts as a bond between what you can see versus what schedule task is there. And it's used in one of the cases recently with AFNIM. Microsoft has a great documentation if you are interested, please check that out. We will see that case if we have some time. So all right, but if you see all this, we don't see the things that we checked for the components, right? The trigger, action, data components and stuff, we don't see it. For that to see, ID will take a note of the GUID and paste it here. It's just the same path, but one above. Instead of trees, we are doing tasks and the GUID that we have. Here you see a lot of information and all the information which is familiar to us. We will not discuss the whole things, but the basic ones, like actions, which is the thing which we should be interested in. What, if it answers what, like here it is running dnspy.exe from the downloads folder. You can see author information who created it. You can see date information, like what date the schedule task is created. You can see the triggers, the conditions when the schedule task will be triggered, it's binary, you have to convert it. And dynamic info, if you are into forensics, some of the interesting timestamps are here. But we will not go to it, but this is the registry structure. We'll see how it is important to us or while you're searching for your data. All right, you better be taking all those notes which we spoke about. So this is what I have for my notes. So it says, I have windows events, task scheduler, operational channels, file creation events, registry keys, and command line arguments, all those things that we see. Perfect. That's a lot of what schedule task and how what artifacts, like I said, most of our time will be in getting those artifacts ready and seeing what artifacts are generated or a specific technique or a tactic. But enough said, let's put that into practice and see how it can give us some information. All right, here, let me set this one up. All right, here we are using Splunk as our SIM, but you can use any SIM and you can convert the queries which we are using here, using sites like encoder.io and stuff. But we will not be doing it, we will using Splunk. We will explain some of the queries that whenever we are searching for it, right? So let's see it. Summon. So the first thing we will do in our threat hunting process or in data gathering process is data sources. If you remember that we did with using Mitre. So here I want to do the same. I want to get what data sources is available. Let me run it and see what I have. Before that, here, we want to answer the question where in our narrow hypothesis, that we said we want to search for all the data that is available to us. So that's why I changed the time to all time. I and schedule task are time frame-based. So you can, sorry, threat hunting can be time frame-based. So you can check for those, right? The query says that index, which is the Splunk way of saying a data that we ingested from a point product or somewhere else. Then we will, with the help of Splunk command DDIP, which exactly says deduplication, we get unique instances of indexes. And finally, we are saying the give us in a table or follow. So if you think back this to our narrow hypothesis, this answer, the table answers how, like how I want to get the data. And the index and the time frame answers where the question. Okay, among these, the first one is Zeke, which is network-based logs. We didn't see anything according to our hypothesis. So we'll skip that. OS query, which is important, which is endpoint data. But in our research, we didn't come across, we can maybe use it in the future, or we can use it for this technique in a different way. But we will keep that in place. Sysmon, which is the data source that we searched for. You can remember this file creation events and the registry events. So we will use them. Windlog events is also important. We checked that that's our first step actually to check some of the Windows events using Microsoft site. So let's start with it. And we have other things like HTML and Velociraptor and stuff. Let's start with the Windlog beats. So if I search for Windlog beats, the first thing we should do is the second, once the data gathering has happened, the third step in our thing is data familiarization. This is important because this is also one which narrates how we will search the data or what fields that we search for data. I just threw a term called fields. Let's see what it is. So if you see the left hand, the red column, they are called fields and the green ones are the values associated with that fields. Here we have some basic information about, this is a sample log that we just picked out of, seeing all the Windows event logs. And in that we see some host information. We see the agent information, like here Windlog beat, how we get the data from the endpoint. We use the Windlog beat in this scenario. Event.code, this, if you remember, is equivalent to event ID that we are interested in. And event provider, like I said, event IDs are specific to a provider and they are a channel, they're not specific, they are not unique to the whole Windows environment. So here it says the provider is Microsoft Windows Time Service. Think about it how we can use this one. We have host information like IP and MAC addresses. We have OS specific information. We have a message feed, which how it looks for, how we, if we see this in the Windows event logs, this is how you see it. We have again, the other information to it, user information also. All right, perfect. So according to our research, what we saw is we want specific event IDs. So let's search for them. So here I'm saying I want, in stuff all indexes, I only want Windows event logs and I'm using event.code, which you remember is the event ID and I'm searching for specific event IDs. But I did not see anything. I don't get anything. Why is that the case? So let's see. All right, let's see why. So here I'm using in operator. That means you can do, I want to search something, some data in a specific field. Here I want to search 4698 in event code and the rest of them. Instead of this, you can also use event.code is equal to 4698 or event.code equal to 4699. You can do this way too, but this is a concise way to search for data. But we didn't find anything. Like I mentioned, lack of data, lack of return of results is also an interesting part in threat hunting and we will see why it's not recap. Okay, let's take an out of that. We didn't find anything, right? Okay, let's search for other data in our little notes that we took. In other things, we saw that we have another channel called Microsoft Taskedular Operational Channel that we can check event data logs related to. So let's check if it is there that we are collecting them because if you remember, MITRE said that if you enable it, right? So here what I'm doing is I'm again saying that I want specifically logs from winlog events and I'm using the operator event or provider that we checked in our example before to getting familiarized with the data in there. I think it's, I believe it's related to prime provider. Here I'm saying that I want any provider that has a name task in it. They have to share, you see, they are related to wildcards so you can use them to find any key what you want and using the ddub exact ddub command. I'm wanting only unique instances of event provider and I'm asking to give me in the table or phone. And all this, if you observe, we are using all time. So we are searching for all the data that is there. Perfect. I see one hit which is better than the last one. So what I will do is I'll take all this and just search for it. So this one here I'm specifically saying, same Windows event logs, but I want only from this event provider. Let's see how the data goes. Let's unroll all the things, okay? Here you see similar information like agent information event code. Here it says event code is 719, but in event action it says something like schedule task operational log was disabled. And if you also see the number of events that we see, we only have five, which doesn't seem right, right? So that means I cannot use any of the first two data points that we have searched for or we took note from MITRE and other things. Okay, not an issue. Let's go move forward with it. Let's see file creation events. Let's see what we have there. For file creation events, if you remember, we checked for Sysmon events. So let's see what Sysmon looks like. So for that, if you remember, we have different indices and in that Sysmon is one of them. We will check for Sysmon data. I'll just pause this to see what sample looks like. So I will do the same that we did for the windows event logs. Let's unroll everything and see what data we have so that we can use, we can see if we can use any of these fields in our search creation. So let's see. Here I'm seeing most of the data that we seen in windows event logs, like the agent version, event category, event action, event core, but event category is kind of interesting because event category says the bulk or the grouping a Sysmon does for a specific event action, like in this case file and event action is specific to this particular category. Like category here is file and action is file created. In the same way, you might have actions for other things too, in other categories. The first, the next thing is event code, which is the Sysmon event ID that we gathered. Provider is the same. And then file information, we have it because this is related to the file category and file creation events. We have file information associated with it, like file directory, name, extension path. If you think about it, this will come handy to us because we are checking for a specific path according to our research. Event host information, we have it as we see before. We have, what else we have? We have this rule name. This is interesting. We have process information because what process creates that file. We have rule name. It specifically says technique ID, technique name, which resembles to MITRE techniques and their names. This comes very handy too. This is coming from the Sysmon config file. When you are configuring your Sysmon events, we will not go into details, but from there you can get this. Okay, good. So as we are familiarized with our data set, we know what categories, we fields we need. We need the event category or event action field. We need the, because we are searching for file creation events. We need event code field. We need the file path because we are looking for a specific path. And also we can use the process information because we are also looking for a specific process. So that said, let's check what we have here. So let me paste that. Okay, Mac. This is a Mac issue, sorry. Yeah, let me paste that. So here I'm saying that I want things from Sysmon only and I want specific to event ID 11, which is equivalent to the file creation events like we see before. I want process executable to be svchose.exe because if you think our notes, we have seen that this one exists from it. Sorry, the file creation events happen from svchose.exe and it happens in a specific folder or a path and that's what we are mentioning here. And I'm using a thing called transaction. It's a way to group events together and I'm asking Splunk to give me in table or file. You get 75 results, but this is where the true threat hunting begins because one of your, if in our threat hunting process, if you remember after querying is interpreting the results and filtering them. Interpreting results is difficult. It based on your known normal of the environment, it based on the OS behavior, is based on the process behavior that we are checking. So there are different things that can influence how you interpret your results while performing the threat hunt. For this, we will use a simple methodology. I don't know where I heard this from, but I heard in one of the conferences or talks, but it goes like commonly observed events across multiple endpoints could be common or something really bad is happening. That means if you see something in different endpoints like this one, Microsoft Office Office Performance Monitor, you're seeing in most of the endpoints that we have, that means this might be common for a OS behavior or our environment or something had already happened and we are in a doodle. But let's go with the first happy thought that it is common in the environment, right? By doing that, we are getting to this monstrous query. We'll get to this monstrous query. Let me run it and I'll tell you what we are doing here. We are doing the exact same thing, CIS monitor 11, SVC host and task builder, but we are removing or filtering out certain things. That filtering happens because of OS behavior like this one, create, explore, shell and elevated task. This could happen because of software updates or software related to operating system like in this case, Microsoft something or a specific program that we have here, Google Update. So let's say this filtering in our environment, CC cleaner is not a genuine process or not an allowed process. You can find those things here too. So it's a catch 22. Threat hunting can help you in finding your no normal, but also if you know you're no normal, then only you can find threat hunting. You can get most of your threat hunting. So you can figure it out how you want to use it or in threat hunting, but most of the time if you have a solid no normal, then it is easier for you to hunt for different things which are abnormal or anomaly in the circumstances. Okay, by filtering it and by the way, a good task for you is you can check for all these events and think of a ways why we filtered it because the reason we filtered it like we mentioned is operating system and stuff but just see what they do so that if you see this anytime in your hunt, you can say that, huh, I know what that is and it's common. I can filter it out or I can filter these out and if I don't find anything I can see for edge cases on might be an attacker using or a perpetrator using legitimate functions in order to do it, which happens in a lot of ways. So anyways, after filtering, we have one task happening on two endpoints, interesting. This is not to say suspicious yet, but it is interesting to see that we have a certain process that is running on two things. So let's search for what it is doing. So let's take this and do a blind search for that. So we will do a blind search on what it is doing. In this we are seeing some of the things like registry value sets. This is interesting because we have seen that registry events will be created when a schedule task is created. We are seeing most of them are, yeah, most of them are related to registry, but easier way instead of going through each log, easier way to find about what we have is this. Let me put a query. So here I'm using the exact command, but transactions, I'm trying to see what hosts are there and grouping things by the host name. And I'm saying the event category field which we saw for Sismon to see what exact actions or event category and event actions to see what exactly it is doing. So here we see file creation events, registry events on both the endpoints. This is interesting because we've seen the exact same things that we have checked in our artifacts whenever a schedule task is created, this is what will happen. Okay, perfect. But anytime you see these interesting things, take a note of it and wait until it becomes suspicious. So here we are doing the exact same thing. So as we see, there are several ways to create command line arguments for schedule tasks. I'm checking for some of the keywords that can happen while performing schedule tasks. Like here, I'm checking for different things, but you can filter out all this. Let's see, just plain. Though let's check this. If I type properly, it will make sense. Okay, so here we are checking that I want the, I want to check for a parent, PowerShell.exe and a child, cmd.exe to see some of the key line arguments for schedule task creations. So this one, I found it in different ways. I can find it in different ways. One is you can see in Microsoft documentation, like you can go to Microsoft SEH tasks. In here, you can check what are the commands that you can use using Microsoft, like change create and stuff. You can use PowerShell documentation. Similarly, you can use WMI. These are basic keywords that you are using in order to find a particular schedule task or what a schedule task is doing, right? Perfect. Let's say with our previous things, if we're using registry and file creations, we determined that particular schedule task daily, Microsoft task is there, is a suspicious one. And in order to check what it is doing, we saw that process creation events. In that process creation events, we see a command line, which matches the command that we are saying here, slash C start. That means command.exe is used to start cleanup.exe and we don't know what cleanup.exe is or we don't know anything about it, but we just search for the keywords. And this is what we found in it. And we saw PowerShell.exe. And if you think about it, think of a bin, general things like temp folder, cleanup.exe. It is using PowerShell.exe to spinup command.exe and starting something from a cleanup folder. Okay, let's see what cleanup folder is doing. Sorry, cleanup.exe is doing. So for that, we will do the basic thing. If I type it, so cleanup.exe, we have 113 events. Again, the best way to do what actions it is performing is using the specific command that we have checked, like teedup. And here we are seeing different things, file created, process terminated, process accessed, blah, blah, blah. This is a good task. Now we have searched for the schedule task which is needed. We found something which looks suspicious and we have seen several things that we can do it. So take any of your things like network creation events or any network detected events, image loaded events. Here we are checking for, so let's go back to the presentation. So here we are just checking for one such events process creation and we have seen this particular thing that we have seen before, that something is starting from a temp folder. So think of it, cleanup.exe starting with CMD.exe using PowerShell from a temp folder on the host that we have checked and it looks suspicious or an interesting schedule task is present. This starts your hunt. Again, most of the time hunting is chasing that goose but with a solid data backing up. Like if one data says something is suspicious, back it up with another data which produces similar artifacts. And that's it. But there is more than that to threat hunting. We only checked one such events. So you can go ahead and check what else is present in all the data or all the artifacts that we gathered. All right, let's recap everything with a small template. We are using a template for that. The title of our hunt is hunting for adversary schedule. We created this on the date. We are notifying our hypothesis. This is our hypothesis in the narrow hypothesis that we got. We are mentioning some of the mitre techniques and tactics. We are using simulation techniques. Like this is very important. If you are simulating something to in order to perform threat hunting or detections, this is interesting. You can note what simulation has performed. And then we're using a proposed search query. Here, this query could be anything. I just mentioned the last search query. But if you can mention all your search queries in it, it helps if someone wants to take this template and wants to reproduce the steps, it helps them a lot. And here, I'm noting some of the limitations of my threat hunting. Like I mentioned, if something didn't turn up in threat hunting, it's also interesting. If you remember, in our case, we haven't seen any logs related to Windows event logs and also Tasked Dealer operational, which says it got disabled because there was no space or something. So this is important because this helps in getting that visibility of how and why I'm not getting this particular data. If I'm not getting, how can I get it? And we also observed when using this methodology for command.exe where we run through different artifacts, only we saw workstation one has cleanup.exe. But if you remember our schedule task, it is running on two workstations. Why that's the case? These questions helps you answer a lot of other things which doesn't always mean that you want to find this grand APT that you're seeing. But these are also byproducts of your threat hunting. It helps you achieve that unknown unknowns and unknown knowns to help secure it. Good. And the last, what did we find? We found a particular task called Magnum Tempest site cleanup on a couple of computers and a cleanup.exe is also launched from a strange location like temp and also has some interesting artifacts even related to a network artifacts. Perfect. Like I mentioned, the detection coverage and visibility. Here through our hands, we have noted that event logs are not there or at least specific to schedule task are not there. So we want to see a way we can get that data. We are, by the looks of it, we have not enabled that operational channel. So we want to enable it so that we can get more data and weigh the benefits and risks of enabling it. We also seen that workstation one only produced the cleanup.exe process creation. We didn't see the other workstation performing it. So that's our visibility. Coming to our detection coverage, like I said, you can stop your hands at the findings and documentation using the template that we did here, but we can also move it a little further. We can use it for our detection coverage. Here we are saying that we can use our query, whichever we used for the threat hunting queries like our process creation events from, or we can use our based on or no normal or filtering capabilities we have seen. We have filtered everything and only one event was left. We can use that as our detection query. You can use a combination of them, right? But that is only one portion of what we did. There are several other use cases in this schedule that's making unusual communications. It is downloading policy of cradles and several other things. You can either create hunts for each and every of these, or you can hunt for the behaviors like we can do, let's say schedule dust, how it is based on the artifacts that we gathered. So you can use either one of them, right? These are all the detections that we can create if we have gathered all the tasks and if we can do those information. And if you see here hidden schedule tasks, if you remember, I said, if you have some time, we will talk about Huffnium, this is what it did. It hide hid its schedule tasks from viewing it. It does using that SD key that we spoke about in registry where it automatically removed that for using com, but it removed it. And when you remove that, you don't have the connection between what you see versus what schedule task is running. So you cannot, it gives a nice behavior to evade the regular hunts that you have. So you can also check for that particular behavior, something like let's say SD registry subkey is deleted using SysPone or any other ETR that you have. So these queries that you use are specific to ETR, it's blank here, but you can convert them into and use it like we said to any others. Finally, that's our talk, all the differences I have followed is mentioned here. And thank you so much for everyone for being patiently watching this. We ran through some of the artifacts, but please go through those artifacts one by one. You can find your own rhythm in, find in searching for those artifacts. We will be releasing a blog post which has detailed information on everything. So please go ahead and check. Please join our Discord channel if possible. So thank you.