[00:18.160 --> 00:22.400] Hello everyone, Arthur Packett here. We have a pre-recorded video for you. [00:22.540 --> 00:28.240] It's an intro to Velociraptor. This is about a 40-minute presentation. We hope you enjoy, [00:28.240 --> 00:32.340] and if you have any questions, please feel free to direct them to the workshop track one [00:32.340 --> 00:37.180] or the Recon Discord server for more immediate answers. We hope you enjoy. [00:40.640 --> 00:46.980] ...video to demonstrate how to install Velociraptor, and we'll just do a quick guided [00:46.980 --> 00:56.760] tour through the Velociraptor features, and have a quick introduction to this new DFIR tool. I mean, [00:56.760 --> 01:02.460] you might have heard of Velociraptor before, and in this video we will show how to install it, [01:02.460 --> 01:09.380] and we'll just do a quick demonstration. So I'm going to start off by... you can see my desktop. [01:09.380 --> 01:16.960] This is a typical Windows system, and I'm going to show you how to install it from scratch in a [01:16.960 --> 01:23.860] little bit, how to actually use it in real DFIR work. So the first thing that I'll do is I'm just [01:23.860 --> 01:33.440] going to go to the GitHub page, and I'm just going to search for a GitHub page for Velociraptor, [01:34.000 --> 01:41.860] and download all the releases. I'm going to show you how to install Velociraptor in the cloud, [01:41.860 --> 01:47.000] on a cloud platform. So the first thing I'll do is I'll download the releases. [01:47.360 --> 01:55.600] I'm going to have a server which will run on Linux, so I'm going to need to download the Linux [01:56.180 --> 02:03.280] binary. I'm also going to run the Windows executable on Windows, so I'm going to need [02:03.280 --> 02:10.860] to download the Windows binary. And also, finally, I'm going to need to download the source code, [02:10.860 --> 02:17.960] so I can show you guys how to build an MSI installer. So once I download these binaries, [02:17.960 --> 02:26.220] I'm going to open a new shell, and I'm just going to run it as administrator, [02:26.980 --> 02:37.120] so I can install the relevant MSIs. And since I just downloaded it into the downloads directory, [02:37.120 --> 02:51.480] I'm just going to change directory to that, like downloads. And if I do a dir, you can see the [02:51.480 --> 02:57.260] binaries that I've just downloaded. Okay, great. So the first thing that we need to do is create [02:58.860 --> 03:06.200] a configuration file in which we can deploy on the server. I'm going to create the configuration [03:06.200 --> 03:12.320] file on the Windows machine, and then I'm going to push it out into the server, create a Debian [03:12.320 --> 03:19.800] package, and push it to a Debian server in the cloud. So first thing I will do is I will generate [03:20.200 --> 03:28.100] a configuration file using the configuration wizard. I'm going to use the dash i flag, [03:28.100 --> 03:33.580] which is the interactive wizard, which will help me generate the configuration. [03:35.580 --> 03:42.060] So it goes off and it will ask me some questions about what exactly, what type of deployment I want [03:42.060 --> 03:46.980] to use, and it will actually create configuration for that. I'll start off, I'm going to be running [03:46.980 --> 03:54.020] it on a Debian machine, so I'll choose a Linux server. File based data store is usually the [03:54.020 --> 04:02.800] simplest, and this is the directory that I'm going to store all the files in. In this particular [04:02.800 --> 04:07.340] example, we're going to create a Let's Encrypt certificate automatically, so it will create [04:07.900 --> 04:14.320] an SSL certificate without any further intervention, and will also authenticate with [04:14.880 --> 04:20.780] standard usernames and passwords. So this is the second option, and I'm going to use one of my [04:21.440 --> 04:30.400] VM machines, training VMs, and this will be the domain name for the training VM. So because we [04:30.400 --> 04:38.220] want to create an SSL certificate, we're going to need DNS to be properly set up. [04:38.720 --> 04:43.860] So we're going to use a real DNS name, and Velociraptor has this really useful feature [04:43.860 --> 04:50.700] where it will actually update dynamic DNS by itself, without us doing anything at all. So [04:50.700 --> 04:56.160] if we use Google Domains for the DynDNS, it will be able to go out and update it. And over here, [04:56.160 --> 05:06.400] I've got the credentials for that, which you can get from the dynamic DNS settings of the [05:06.400 --> 05:15.920] Google Domains. So I just literally copied them into the prompt here. [05:17.100 --> 05:22.780] And then it will ask me to create a new user. This is the initial administrative user that [05:22.780 --> 05:30.360] will be created when the service installs. So I'm going to just create a new user and give it [05:31.660 --> 05:38.600] a password here, and then just press enter. It will generate some keys, [05:38.600 --> 05:43.720] finish configuring it, and you can see that it created a server config and a client config. [05:43.720 --> 05:49.060] If I have a look at the files, then we have the server configuration, and then the client [05:49.060 --> 05:54.240] configuration, which contain the keys, the key material, and all the configuration. [05:55.080 --> 06:05.120] So the next step is simply to create a server Debian package using that configuration. So we're [06:05.120 --> 06:11.520] going to run Velociraptor again and tell it to use the server configuration and Debian [06:13.620 --> 06:18.880] server. So we're just asking it to create a Debian package for the server. [06:20.060 --> 06:27.520] If we just try to do this now, then it will say, I don't actually have a Linux binary, [06:27.520 --> 06:32.640] so you're running a Windows binary and you're asking me to build a Debian package, so I need [06:32.640 --> 06:39.160] the Linux binary as well. So in this scenario, we're going to need to give it the Linux binary [06:39.160 --> 06:48.440] to actually package as well. So we do that, and it will actually build us a Debian package. Let's [06:48.440 --> 06:54.680] have a look. And we can see that there is a Debian package here that contains the configuration [06:54.680 --> 07:00.360] embedded with it and all the startup scripts and it's all the service configuration. So all we have [07:00.360 --> 07:07.680] to really do is now just push that to our cloud endpoint and then start it. So I'm just going to [07:07.680 --> 07:18.940] scp it to my cloud machine and over here I've got my IP address of my cloud machine [07:22.900 --> 07:31.280] and it will just copy the Debian package over there. [07:32.640 --> 07:36.800] So now I will ssh to that machine and install it. [07:41.020 --> 07:45.740] Okay, and if we have a look at my home directory, there is the Debian package there. [07:46.260 --> 07:55.660] So I just install it with the package and it's going to head and install the service [07:55.660 --> 08:01.240] and create it. So it's already pre-configured to start and it should just work, [08:01.240 --> 08:06.540] should bring up the service. I can check the service is up, service [08:14.840 --> 08:23.680] status, and it shows me green, active, running, and it's all ready to go. So now if I go to that [08:23.680 --> 08:38.260] with HTTPS, vm1.training.velocidex.com, then I should be able to log in with the username and [08:38.260 --> 08:44.720] password that I gave it before in the configuration file. So now we have a Velociraptor server set up. [08:44.860 --> 08:52.280] It only takes a minute. You can see down here the version and this is the GUI. This is great, [08:52.280 --> 08:56.120] so that's the server, but we still don't have any clients attached to it [08:56.120 --> 09:00.820] because we haven't really deployed the client side of it. So now I'm going to show you how to [09:00.820 --> 09:09.260] create an MSI for being able to deploy on the Windows platform. So let me get out of there. [09:10.800 --> 09:18.880] So we'll go back to our downloads that we had here. And to build an MSI, we use a tool called [09:18.880 --> 09:26.700] Wix, which is a typical MSI framework build framework. And it's very easy to do. [09:26.940 --> 09:33.420] Let me just open the source code, which we downloaded from the GitHub page. And in the [09:33.420 --> 09:39.620] docs directory, you will find a directory called Wix. And this directory contains all the scripts [09:39.620 --> 09:49.160] required to build the Wix, to use Wix to build the MSI. So I'm just going to paste it [09:49.780 --> 09:54.680] and just extract that one directory into the downloads directory. [09:56.060 --> 10:01.400] Okay, so I can see it here. And let me go into it. [10:02.260 --> 10:08.100] And I'll just quickly show you guys all the scripts here. We have a number of different [10:08.100 --> 10:14.100] scripts. And what we want to do is we want to build in this case, a customized version [10:14.660 --> 10:21.300] of our MSI that already embeds our special configuration. So that MSI will be used can [10:21.300 --> 10:28.050] be used to then deploy using any number of software management tools like [10:30.450 --> 10:39.510] Group Policy or SCCM or anything like that. So in order for these scripts to work, [10:39.510 --> 10:47.830] I need to create a directory called output and copy into it the binary that I want to deploy, [10:47.830 --> 10:55.790] which would be the Windows binary. I'll put and call it velociraptor.exe. [10:55.790 --> 11:01.530] Okay, additionally, I want to copy the client configuration [11:02.830 --> 11:10.410] into the output directory as well. So now I have two files in the output directory. [11:10.410 --> 11:15.810] And these two files will be packaged. That's really all it is that's required to be packaged [11:16.350 --> 11:25.170] in the MSI. So I'm just going to run the build custom script to create the custom MSI for me. [11:25.790 --> 11:33.070] And all it does is it simply runs the Wix tool set with the right scripts and options [11:33.070 --> 11:41.210] to just build the MSI. It's going to take a second and it will just create an MSI that I can then use. [11:43.610 --> 11:55.950] Okay, so okay, now if I have a look, there is custom MSI here ready for me to build, [11:55.950 --> 12:00.250] to deploy. So I'm just going to install it on my machine here. [12:02.810 --> 12:10.270] And it will just install Velociraptor and it's ready to go. Okay, so that's all it took. [12:10.370 --> 12:13.970] And if we have a look at it over here, and we should be able to see the client [12:14.910 --> 12:19.750] already checking in. So it's installed it on this machine and checked into that [12:20.510 --> 12:24.990] Debian machine in the cloud that's running the server. So that is really all that's required [12:24.990 --> 12:31.230] to deploy Velociraptor client and server. So now I would actually just take that MSI [12:31.230 --> 12:36.870] and deploy it across the fleet and get all the endpoints. So that's great. So we've actually [12:36.870 --> 12:43.390] managed to install Velociraptor in a few minutes with a proper SSL certificate, [12:44.150 --> 12:50.770] automatic DynDNS setup, and it's ready to go. We've seen all the clients. [12:50.770 --> 12:58.430] And now what can we do with these clients? So let me just give you guys a quick introduction [12:58.430 --> 13:06.310] to the UI. Okay, so when you first go to the Velociraptor UI, you will see the dashboard. [13:06.890 --> 13:10.010] Over here on the left side, you can see the number of different options [13:10.650 --> 13:20.070] of the different screens of the UI. The home screen is just a dashboard that tells you a [13:20.070 --> 13:26.570] of the server. You can see how many connected clients there are. And over here, you can see [13:26.570 --> 13:35.050] all the GUI users that are currently configured and what kind of roles they have. You can see [13:35.050 --> 13:41.370] that I only created one user called administrator. I can create other ones. And then over here, [13:41.370 --> 13:47.130] we can see there is a server version with the version of the server that's currently running. [13:48.410 --> 13:55.190] So that's great. Normally, when I would use Velociraptor, I might want to look at a specific [13:55.190 --> 14:01.770] endpoint. So I would usually search for it. And over here, there's a search box. I can use [14:02.930 --> 14:11.990] the host name. You can see that it has some kind of completion going on here. Or I can actually [14:11.990 --> 14:19.210] label machines. You can see I can take this machine and create a label. And let's say I call [14:19.210 --> 14:26.950] it test. The label can be anything, but it simply adds the label to that machine. So now it's called [14:26.950 --> 14:35.050] test. Now I can actually search for label test. And labels are useful later on when we do hunting [14:35.050 --> 14:41.870] and so on. We can select specific labels. So once we search for a machine that we want to look at, [14:41.990 --> 14:48.050] in more detail, we can just click on it. And this is just an overview screen to show us [14:48.710 --> 14:55.750] what this machine is all about. This is a Windows server data center machine. And then we've got [14:55.750 --> 15:01.250] some basic information about it. In this screen, probably the most important thing is the agent [15:01.250 --> 15:08.970] version and when it was last seen and the last IP address that we've seen coming from that machine. [15:08.970 --> 15:15.830] If we click over to the drill down page, then we can see more details about it, [15:15.830 --> 15:22.630] about the machine. You can see more information about the platform and all that sort of stuff. [15:22.630 --> 15:29.870] But this is probably a more interesting thing. It shows us the footprint of the agent on the [15:29.870 --> 15:38.210] endpoint. So we can see that it takes like 35, around 35 megabytes of memory. And [15:38.210 --> 15:43.990] the CPU load is virtually zero because the agent's not really doing anything. [15:44.030 --> 15:48.470] So when we do some heavy hunting and we might actually do a lot more work on the machine [15:49.210 --> 15:54.210] on the endpoint, then it's useful to see how much memory we're actually using and how much [15:54.210 --> 16:00.830] impact we're having on the endpoints. And then this particular one shows us also [16:01.700 --> 16:07.350] the users that exist on the endpoints. But this is just kind of an overview [16:07.950 --> 16:11.450] information about it. We always collect telemetry so you can always see [16:12.190 --> 16:19.430] the most recent telemetry from the endpoint about footprint and so on. The next tab over [16:19.430 --> 16:25.870] shows us the interactive shell. This is an easy UI that allows us to just create, [16:25.870 --> 16:31.150] just run shell commands on the machine. We try generally not to run too many shell commands [16:31.150 --> 16:36.890] because they can be unpredictable, but it's possible to just break into a shell. [16:37.070 --> 16:42.690] Over here we've got a number of different options. We can run our shell commands through PowerShell [16:42.690 --> 16:49.210] or CommandShell or Bash. Usually I would prefer to run with PowerShell because it's just a little [16:49.210 --> 16:58.310] more reliable with regards to escaping quotes and stuff like that. So here's an example, [16:58.310 --> 17:06.330] ipconfig slash all examples will show us everything about the interface. [17:06.330 --> 17:12.010] You can see that over here, this is the time and who ran the command. So when you have multiple [17:12.010 --> 17:18.790] users, you can see who actually issued this shell command. And over here we have kind of a little [17:18.790 --> 17:25.910] bit of a UI here that kind of hides the results a little bit. When you have many shell commands, [17:25.910 --> 17:33.850] then it's easy to see, it's really easy to lose it. So it allows you to kind of hide them a little [17:33.850 --> 17:40.170] bit. And this one just kind of hides them inside of a kind of indented cell. So it's just the UI [17:40.170 --> 17:49.450] kind of feature. But we can essentially type something else, google.com, [17:49.450 --> 17:54.750] and then run it. And you'll see that this spinner will just wait while the command is running. [17:55.470 --> 18:00.090] And then when they complete, we will see the results. So we can see that [18:00.090 --> 18:07.770] the results. So this is kind of handy when you have to do interactively look at the machine. [18:10.170 --> 18:18.110] The next one over is the VFS. The VFS is a way for us to interactively examine the machine, [18:18.110 --> 18:25.610] the machine's file system. So over here we have these are accesses, different types of things [18:25.610 --> 18:32.090] that we can look at. And what we're looking at here is really just the server's cache of [18:33.590 --> 18:40.910] what the file system sort of looks like. But it isn't just checking the file system on the [18:40.910 --> 18:47.830] endpoint. It's just what it already knows about. So when you navigate to a directory that hasn't [18:47.830 --> 18:53.030] been listed before, then it doesn't know about it. And it tells you no data available for this [18:53.030 --> 18:59.590] directory. So initially, there will be no data available. So you can click on this button here [18:59.590 --> 19:06.910] to refresh the directory. And what it will do is it will just issue a directory refresh query to [19:06.910 --> 19:13.470] the endpoint and just list the directory, and then refresh the server's view of it. [19:13.650 --> 19:19.310] So you can sort of go through and click and refresh, click and refresh. Or you can simply [19:19.310 --> 19:27.730] just do this recursive refresh, and it just goes off. And it takes a little bit longer, [19:27.730 --> 19:36.090] but it just recursively refreshes all the subdirectories. So you can kind of look through [19:36.090 --> 19:42.750] them without having to click all the time. So this is a bit of a UI thing. And for example, [19:42.750 --> 19:50.950] if we have a look at our files, we can have... for instance, you would know that there is an [19:50.950 --> 20:01.710] ntuser.dat in the user's home directory. And we don't actually have the data, we just know about [20:01.710 --> 20:07.030] it. So we listed the directory. And if we actually want to see that file, then we can fetch that file [20:07.030 --> 20:12.650] specifically from the endpoint. So we can just click on this thing, and it goes off and fetches [20:12.650 --> 20:19.190] it. And then we'll have a little icon here, which is, you know, just indicates that the server has [20:19.270 --> 20:24.890] a copy of that file now. So we're able to see it from the server, and we can also download it and [20:25.430 --> 20:31.550] things like that. And for those of you who know, you would have seen that typically the ntuser.dat [20:31.550 --> 20:38.310] is locked when a user is logged in, but Velociraptor will fall back to raw NTFS parsing [20:38.930 --> 20:44.870] in case it's locked. So it will actually retrieve the data, even if it's locked. And you can see [20:44.870 --> 20:53.550] hex view and so on. So that's essentially the VFS view, which is the virtual file system. [20:53.750 --> 20:59.530] And it's just a view over in the NTFS. I think we can actually see [21:01.030 --> 21:06.430] what it looks like in a raw NTFS parser. So we can see all those hidden files [21:06.430 --> 21:11.190] like the MFD, and we can collect the MFD in exactly the same way as we did before [21:12.050 --> 21:19.990] from the server, just by pressing this button. MFD is somewhat larger, [21:19.990 --> 21:26.610] so it's going to take a little bit longer. Okay, so the question is, what are we doing [21:26.610 --> 21:32.330] when we're pressing these GUI buttons? And we can essentially just look at it in the same way [21:32.810 --> 21:38.610] and download it and so forth. So you might wonder what is actually happening here [21:39.060 --> 21:47.230] with the Velociraptor endpoints? Well, Velociraptor is really a VQL engine. It just [21:47.230 --> 21:54.950] runs these query languages. VQL is the query language that runs the entire Velociraptor [21:54.950 --> 22:02.670] architecture. When we click on the UI, what we're doing is we're issuing VQL queries [22:02.670 --> 22:06.860] on the endpoints. We're just issuing different kinds of queries. [22:08.070 --> 22:15.090] And so if we go back to our overview here, then we have the Collector tab. [22:15.810 --> 22:19.820] And this Collector tab shows us all the artifacts that we've collected. [22:20.250 --> 22:29.590] So an artifact is simply a VQL query. So every time we click through the UI [22:29.590 --> 22:36.130] behind the scenes, the UI simply issues a different kind of artifact to collect from [22:36.130 --> 22:42.890] the endpoints. In other words, it just simply issues different kinds of VQL queries. And you [22:42.890 --> 22:50.050] can see that by simply looking at the Request tab. The Request tab is showing us all the raw [22:50.050 --> 22:58.450] requests that is going out to each endpoint. And we can see over here, queries. This is the VQL [22:58.450 --> 23:03.790] queries that are going out. So really, whenever we talk to the endpoint, all we're doing is sending [23:03.790 --> 23:13.370] VQL queries to the endpoint. And that's basically all it is. So for instance, here, when we ran the [23:13.370 --> 23:18.570] PowerShell, we're looking at different PowerShell and we can see, you know, we sent a command, [23:18.570 --> 23:26.730] that was the query, and so on. Let's have a look. So when the query is going to the endpoint, [23:26.730 --> 23:32.550] then it will execute on the endpoint. And the next tab that's interesting is the query log. [23:32.550 --> 23:37.690] So as the query is executing on the endpoint, the endpoint is logging some interesting [23:38.430 --> 23:44.670] things about the query, so like errors or anything like that. So we can see over here, [23:44.670 --> 23:52.530] that as the query is running, we get logs. And then finally, it tells us how many rows [23:52.530 --> 23:58.130] the query is returning, because ultimately, all queries just return rows, because, you know, [23:58.130 --> 24:05.570] it's just a query. So the results tab simply shows us the rows that are returned for each query. [24:05.570 --> 24:12.890] In this case, when we ran the PowerShell, it just returns a row and has a column called std out, [24:12.890 --> 24:18.130] and then std error and the return code. Over here, when we listed the directory, [24:18.860 --> 24:26.350] it has a bigger query, and it returns more rows and more columns. But ultimately, [24:26.350 --> 24:32.130] it's still the same. It's just a table. Everything we do is just a table that's returning. [24:32.810 --> 24:41.510] All the queries are simply tables. So we looked at the VFS UI, and it's kind of a nice UI. It's [24:41.510 --> 24:48.010] intuitive, and it's kind of what we're used to when we look at, you know, Windows Explorer, [24:48.010 --> 24:53.090] something like that, people quite understand this sort of file system hierarchy. But we've [24:53.090 --> 24:57.590] seen that it actually just creates artifact collections in the background, but we can [24:57.590 --> 25:03.090] actually just collect other artifacts. So if we click on this plus button here, [25:03.090 --> 25:09.410] we will collect a new artifact. And over here, we have a search screen. So we can search for [25:09.710 --> 25:19.270] a number of different kind of artifacts. For example, a prefetch artifact. So as you know, [25:19.270 --> 25:28.530] prefetch is a set of files that are stored in the Windows prefetch folder, and they maintain [25:29.590 --> 25:35.810] a list of information about executables that are typically run. But one of the cool things about [25:35.810 --> 25:45.070] them is that they actually maintain a timeline of each executable when it was run. So it's often [25:45.070 --> 25:52.770] useful to build a timeline based on the prefetch information, because then we will be able to [25:53.850 --> 25:59.390] pinpoint when a particular binary was run, which might be useful for a GFIR investigation. [25:59.390 --> 26:08.610] So we can choose the prefetch artifact. And we can see that the artifact gives us a bit [26:08.610 --> 26:14.510] of an explanation about what it is that it's doing, a little bit of background information, [26:14.510 --> 26:20.810] then it can take a bunch of parameters. And over here, we can see this is the PQL source [26:20.810 --> 26:25.810] that's actually going to run. So we can look at it. But we don't really need to kind of understand [26:25.810 --> 26:30.770] it too much. If we want to collect this, we simply click add. And then we will fold that [26:30.770 --> 26:37.810] top pane up. So that will give us access to all the parameters that we can configure. [26:38.450 --> 26:45.310] And the parameters are actually then used to control the query, the VQL query, [26:45.310 --> 26:51.130] or by the artifact. But you know, here we can, this particular artifact allows us to filter by [26:52.050 --> 26:57.370] timestamps or, you know, or binary regular expressions or other things like this. [26:58.830 --> 27:05.550] So, but we're just going to just run it, but usually the defaults do kind of the right thing. [27:05.630 --> 27:11.770] So when we run it, it will immediately issue that collection and collect that from the endpoint. [27:12.290 --> 27:19.090] Right? So it basically goes off and builds a timeline from the prefetch data. So every time [27:19.090 --> 27:26.510] we run a binary, it has some, some timing here. So this is really great, right? We basically can, [27:26.510 --> 27:32.430] can see what, what the results are. Right? Another very interesting one is to look for [27:32.430 --> 27:42.790] scheduled tasks, scheduled tasks, because that's a pretty common, a pretty common persistence [27:42.790 --> 27:49.070] mechanism. And then, you know, all we have to do is simply click add and then just launch it. [27:49.750 --> 27:56.990] And off we go. It just, it goes off and calculates it and take a couple of seconds and do that. [27:57.770 --> 28:01.990] Okay. And then we have the results here. So this is basically how we would collect [28:02.930 --> 28:07.130] a bunch of information. Right? [28:10.130 --> 28:14.930] So, so far it was kind of nice. We collected specific information from the endpoint [28:14.930 --> 28:21.550] about prefetch, about task scheduler, et cetera. What if we wanted to collect it from all our [28:21.550 --> 28:27.190] machines at once? We have, I mean, in this case, we only have one machine connected to this [28:27.190 --> 28:32.470] deployment, but typically we might have say 10,000 endpoints connected to the deployment. [28:33.010 --> 28:39.070] When we want to collect the same artifact from many machines at once, we call this a hunt. And [28:39.070 --> 28:45.530] over here we have the hunt manager, which is exactly the same idea, except it just automatically [28:45.530 --> 28:52.750] collects it from all the machines that are connected at once. So we have a similar GUI, [28:52.750 --> 28:59.470] very similar UI to before, right? Except now we're doing it in a hunt. So let's just say that we [28:59.470 --> 29:06.850] wanted to find all the information about running processes. So we wanted to use PSLIST as a hunt. [29:06.850 --> 29:14.250] So we just choose add, and again, we can configure it somehow and see that we can [29:14.250 --> 29:21.710] do a regular expression for which processes we want to look at and so on. But this time, [29:21.710 --> 29:28.190] hunt has an expiry. What this means is that once we start this hunt, it will just continue running [29:28.190 --> 29:34.470] until the expiry time. And anytime a new machine comes back online and connects to our endpoint, [29:34.470 --> 29:40.190] it will pick that collection up and it will just run it. So we don't have to [29:40.930 --> 29:47.350] catch the machine when it's on. Basically, we just schedule it and it will just run it when [29:47.350 --> 29:58.090] the machine comes online in its convenience, right? So we click next. We can specify description, [29:58.730 --> 30:02.270] process listing, let's say. [30:03.830 --> 30:11.970] Next. And here we can choose to run it everywhere or just choose the right labels. If you recall [30:11.970 --> 30:17.410] before, we created the label before. We'll test. We can simply restrict it to all those machines [30:17.410 --> 30:25.130] that have that label or run everywhere. And run everywhere will assign the hunt to all the [30:25.130 --> 30:30.930] machines. So we click next. Now it's showing us this is going to be the request. This is what [30:30.930 --> 30:38.430] we're going to be sending. Looks good. Let's go. When we create the hunt, it's created in a paused [30:38.430 --> 30:47.230] state. So it's not actually running yet. We click start to actually start it. And off it goes. [30:47.310 --> 30:52.130] As soon as we click start, it schedules it to all the machines that are currently connected. [30:52.130 --> 31:03.510] So far, it's only got one machine. And it's finished. So as soon as the machines will finish, [31:03.510 --> 31:09.510] it essentially creates that. We can have a look at all the clients that are connected. There's [31:09.510 --> 31:16.370] really only one in this case, but there could be many more. The status tab shows us if there's [31:16.370 --> 31:22.190] any errors. And over here, we can see the results of the hunt. [31:23.410 --> 31:27.990] So over here, we can see this is a process listing of this machine. [31:30.630 --> 31:38.690] If we wanted to process this data using another tool, then we simply need to prepare a download [31:38.690 --> 31:45.450] over here. And it will create a zip file that contains all of the information in this hunt from [31:45.450 --> 31:50.570] all the machines. Let's take a look. What does the zip file look like? This is only going to be [31:50.710 --> 31:57.070] a small one because it's really only the one machine. But we're going to see a CSV and adjacent [31:57.070 --> 32:04.990] file of all of the results combined from all the machines. And as well as that, we actually have [32:05.570 --> 32:13.010] the collection split up for each machine. These are the logs. And these are the artifacts that [32:13.010 --> 32:18.510] we ended up collecting as part of these hunts. So that sort of split up individually and combined. [32:19.470 --> 32:25.790] And also, if any of these hunts collect files, then we will be able to get that in the zip as [32:25.790 --> 32:34.210] well. So this is just a way that we can use to export data. Now over here, you can see that [32:34.210 --> 32:40.570] it's still kind of in the running state. And some people are confused by that. But this is just, [32:40.570 --> 32:47.150] that hunts always run, they simply expire. So when we created until the expiry time, [32:47.150 --> 32:52.270] when we started till the expiry time, for that time period, it will be active, and then it will [32:52.270 --> 32:58.610] become stopped by itself. And it will no stop means that it no longer accepts new [32:59.070 --> 33:05.010] new clients that come online at that time. So that's, that's basically hunts. [33:06.210 --> 33:11.270] Okay, so that's, that's pretty cool. We can see how we can export the data and use it in another [33:11.270 --> 33:19.030] tool. Sometimes, we really want to be able to post process the data within the tool within [33:19.030 --> 33:28.270] FlossRaptor. So the next feature I wanted to show you guys is the notebook feature. [33:28.270 --> 33:37.470] Notebook is basically like a collaborative analyst tool that we can use to, to analyze [33:38.080 --> 33:43.580] the results from a particular investigation, put them together and post process them. [33:43.950 --> 33:50.970] So I'm just going to show you quickly how I would build a notebook. So I would click this plus [33:50.970 --> 33:57.990] button here, which creates a new notebook. And I can call it whatever I want, like test notebook, [33:57.990 --> 34:05.490] for example, give it some description. And here I can choose collaborators that I would [34:05.490 --> 34:10.830] like to collaborate. So it's like a collaborating, you know, a Google Doc or something like that is [34:10.830 --> 34:19.310] it's very pretty familiar concept. When I submit it, it will create a new notebook over here. And, [34:19.310 --> 34:25.010] and you'll see that down here we have the title will be copied into here. So that over here, [34:25.010 --> 34:29.530] we can see all the notebooks that I currently have. And when I click over here, I have to [34:29.530 --> 34:36.450] actually click on the title itself to bring it into focus. And I will see that it creates, [34:36.450 --> 34:42.850] this is called a cell. So a notebook is consisting of different cells. And over here, again, [34:42.850 --> 34:49.630] this is called a markdown cells. You can see its type is markdown. So I can simply use, [34:49.630 --> 34:54.850] just describe this. And normally I would put like some background for the investigation. [34:55.450 --> 35:06.030] Demo cell for demo. Right. And I actually can also copy paste, copy image, [35:06.030 --> 35:10.070] take a screenshot. I can actually paste the image in here. [35:11.650 --> 35:17.010] Right. And this is just markdown. If you're familiar with the markdown, it's very, very [35:17.010 --> 35:23.550] familiar. When we save it, it simply renders it. So it's just a markdown here where I can put some [35:23.550 --> 35:29.650] notes. So that's not the most interesting thing, but let's say that I wanted to do more [35:30.350 --> 35:36.870] interesting post-processing. Well, I can create another cell and add it from a particular flow [35:36.870 --> 35:44.590] or hunt that I've created previously. So from a particular collection. So let's just add cell [35:44.590 --> 35:52.150] from flow. I choose the client and these are the flows that ran before. Right. So here I've got my [35:52.150 --> 36:00.510] task schedule, for instance. So all this does is it creates VQL. It pre-fills the VQL for me with [36:00.510 --> 36:08.750] the right cell IDs and all this sort of stuff. This is simply a VQL query that just post-processes [36:08.750 --> 36:12.150] the information that we've already collected. So it doesn't go out to the client and collect [36:12.150 --> 36:20.130] the information again. It just post-processes it. It's useful in order for us to see, [36:21.090 --> 36:26.930] to be able to post-process it and filter it and so on. So for instance, in this particular case, [36:26.930 --> 36:32.690] we are looking at task schedule and this task scheduler. And, you know, maybe a particular [36:34.030 --> 36:43.030] malicious task would have maybe PowerShell. We wanted to know which tasks are running [36:44.670 --> 36:50.110] PowerShell. So this one will return all the tasks. And now we would like to filter it. [36:50.130 --> 36:57.490] Where commands, and this is the regular expression operator, [36:57.490 --> 37:05.730] matches PowerShell. Okay. And then if I press save, okay, there's no PowerShell here. [37:08.070 --> 37:25.030] Okay. So we have Google update or whatever. So you can basically run DLL is a common, [37:25.030 --> 37:34.130] this machine is not actually owned, but is not compromised, but so you can see it. So here, [37:34.130 --> 37:39.430] for example, we can filter by run DLL, see all the, all the commands that have run DLL. [37:39.570 --> 37:45.850] So this allows us to do these post-processing kind of operations. We can do the same thing, [37:45.850 --> 37:53.750] add cell from hunt and looking at our process listing hunt, same thing. It simply creates [37:53.750 --> 38:01.950] the table for us, the query for us initially, right? So for instance, we can say where, [38:07.320 --> 38:16.200] where name matches Velociraptor to see all the Velociraptor processes that are running. [38:16.200 --> 38:21.200] We can see there it is. The Velociraptor process is running. That's the hashes. [38:21.200 --> 38:26.860] That's the authentic code information. Is it signed? Yes, it is. And so on. So we can get [38:26.860 --> 38:32.780] this kind of high level information and the username is running it as a system. So this is [38:32.900 --> 38:42.020] a pretty cool, cool way of post-processing the different, different things. So I'm not going to [38:42.020 --> 38:48.380] get into too much into the, the artifacts and how to actually write the QL, but as a process to say [38:48.380 --> 38:54.760] that in this screen here, we can view all the different artifacts and let's just reiterate [38:54.760 --> 39:03.340] again, what an artifact is. As I said Velociraptor simply runs VQL, but if the UI simply required you [39:03.340 --> 39:09.020] to type a new query each time, and that would be very tedious and error prone, and it would just [39:09.020 --> 39:15.740] not be a very good user experience. So with Velociraptor, we have a concept of artifacts [39:15.740 --> 39:26.080] and artifact is simply a YAML file that contains the descriptions behind the particular VQL and [39:26.080 --> 39:35.260] the VQL itself. So let's have a look at something like, let's say the DNS, DNS cache. This is an [39:35.260 --> 39:42.040] example of a, of an artifact. And you can see that here in this screen, we can view all the [39:42.040 --> 39:46.960] different artifacts and we can actually edit them as well. So this particular artifact, [39:46.960 --> 39:53.540] you can see that it has some VQL here. It just queries the DNS cache on a Windows system. [39:53.780 --> 40:02.080] So we have some explanation of what it does, and then it just, it just does it right. So, [40:02.580 --> 40:12.020] so let's have a look at what does it look like in, we said it's a YAML file. So if we click the, [40:12.020 --> 40:17.340] to edit it a little bit. And so you can see that we can customize using this UI, [40:17.340 --> 40:24.720] we can customize the artifact. So we can simply add in here, the, the different, [40:24.720 --> 40:30.300] different things, right? So, you know, we could say, Oh, okay. You know, if we, maybe we wanted [40:30.300 --> 40:40.100] to add a filter or something else, we can simply, we can change this as required or write our own. [40:40.100 --> 40:46.700] And so we can go over here for instance, and let's open a new tab. [40:51.760 --> 41:04.870] Collected cache. Okay. Let's collect the DNS cache again. And it's very quick to do, to do that. [41:04.870 --> 41:11.390] As soon as we ask to collect it, it will, it will essentially do it instantly. It goes out to the [41:11.390 --> 41:17.710] end point and collects it instantly. And we can see all the different, all the different DNS names [41:17.710 --> 41:24.710] that are in cache at the moment. So hopefully this was a quick, short introduction to Velociraptor. [41:24.710 --> 41:30.830] We went through the installation process, which only took a couple of minutes. And then we went [41:30.830 --> 41:38.870] through some of the things that we can do with it. Again, the sky's the limit, really. We can [41:38.870 --> 41:43.850] collect different things and we would normally respond to the different incidents and collect, [41:44.990 --> 41:53.690] you know, connect different artifacts to, you know, all the time. But, you know, it's, [41:53.690 --> 42:01.150] it's just a very powerful tool that allows us to gain unprecedented visibility of the endpoints [42:01.670 --> 42:07.810] that we really can't get with other tools currently. Okay. Thanks for watching. [42:09.730 --> 42:15.750] And yeah, if you're interested in Velociraptor, have a look, go to the GitHub [42:15.750 --> 42:21.450] and download it. It's open source. And also contribute and join our community. [42:22.050 --> 42:26.210] Thanks again for listening. Thanks.