WEBVTT 00:00.000 --> 00:11.200 Thank you very much for being here, and thank you for allowing us to be here. 00:11.200 --> 00:17.320 Our talk is called How to Do You I Do That. 00:17.320 --> 00:22.000 We're visiting here today from Fox IT in the Netherlands, like I said, for I have to 00:22.000 --> 00:23.000 be here. 00:23.000 --> 00:28.680 My name is Leonard Habsma, I'm not much of a developer per se, get I am here. 00:29.680 --> 00:31.680 He is the main developer. 00:31.680 --> 00:37.680 I've been working at Fox IT for 15 years, I worked as the incident handler in the cybersecurity team. 00:37.680 --> 00:44.680 So mostly incident and investigating the store breaches. 00:44.680 --> 00:51.680 Now to work to my former intern, who has been outpacing me technically in any possible way. 00:51.680 --> 00:55.680 Yeah, so I'm still following everywhere it goes, you know, so it's thanks to his butt. 00:55.680 --> 01:02.680 My name is Eric, I've been at Fox IT for 10 years now, so 10 years ago I was his intern. 01:02.680 --> 01:06.680 And I am a security researcher, I'm a security researcher team. 01:06.680 --> 01:13.680 I mostly do R&D, but also to his response, sometimes help at Ratteam, like just do whatever 01:13.680 --> 01:15.680 really crosses my guess. 01:15.680 --> 01:20.680 I am the author of Disact, which is kind of like the framework we're going to be talking about today. 01:20.680 --> 01:24.680 And we'll take it off. 01:24.680 --> 01:26.680 Perfect. 01:26.680 --> 01:32.680 So what is Disact? Does anyone here know Disact or has used Disact in the past? 01:32.680 --> 01:35.680 A few hands, a few hands? Okay, good, good, good. 01:35.680 --> 01:37.680 So then it's good you have a little bit of an introduction. 01:37.680 --> 01:43.680 Disact is a pure Python, no dependencies, open source, forensic investigation framework. 01:43.680 --> 01:48.680 So as said, no dependencies, so everything's implemented purely in Python, 01:48.680 --> 01:50.680 we're trying to support many formats as possible. 01:50.680 --> 01:54.680 And currently, Disact is being developed by Fox IT, 01:54.680 --> 01:56.680 we're part of NC group. 01:56.680 --> 02:00.680 But we are seeing more and more contributions from various parties, 02:00.680 --> 02:04.680 primarily in the Netherlands, but also outside of the Netherlands. 02:04.680 --> 02:07.680 So where would you use Disact 4? 02:07.680 --> 02:09.680 I would like to know more workflow. 02:09.680 --> 02:10.680 It looks something like this. 02:10.680 --> 02:11.680 Or you're an analyst. 02:11.680 --> 02:13.680 You have some investigative material, 02:13.680 --> 02:16.680 and you want to get readable information from that. 02:16.680 --> 02:21.680 But your investigative material is oftentimes in various different formats. 02:21.680 --> 02:26.680 And Disact comes to the rescue to allow you to access all the artifacts, 02:26.680 --> 02:34.680 like high level artifacts like run keys or system services in a way that's readable in records. 02:34.680 --> 02:36.680 We'll get to that a little bit later. 02:36.680 --> 02:43.680 And to go as to have a little specific parser that require an artifact to be in a specific format 02:43.680 --> 02:47.680 as possible, but to have everything working more generic. 02:47.680 --> 02:51.680 So I have a little bit of an example of that, how that would look like. 02:51.680 --> 02:53.680 You have, again, your analyst. 02:53.680 --> 02:57.680 And you have a image called evidence of raw, 02:57.680 --> 02:59.680 which is like a Linux server, for example, 02:59.680 --> 03:04.680 and you would like to know what command line commands were issued on that system. 03:04.680 --> 03:07.680 So we have a plugin for that that will do that. 03:07.680 --> 03:09.680 It's called command history. 03:09.680 --> 03:13.680 And you can run diesect in a way of target query, 03:13.680 --> 03:16.680 which is one of the tools part of the diesect suite. 03:16.680 --> 03:19.680 And with the minus f, like function, 03:19.680 --> 03:24.680 you can run the command history plugin on your raw disk image. 03:24.680 --> 03:26.680 And what will happen in background? 03:26.680 --> 03:30.680 Diesect will see that it is a raw disk image. 03:30.680 --> 03:33.680 And we'll load that disk image. 03:33.680 --> 03:37.680 It will see that it has a certain file system in this case. 03:38.680 --> 03:41.680 It will see that to Linux file system, a Linux operating system, 03:41.680 --> 03:47.680 it will see what it needs to do for the command history plugin in this case. 03:47.680 --> 03:50.680 And once the command history plugin runs, 03:50.680 --> 03:51.680 it will do a number of things. 03:51.680 --> 03:54.680 It will iterate through the existing user. 03:54.680 --> 03:56.680 Users that exist on that system. 03:56.680 --> 04:00.680 It will go through the various history files, 04:00.680 --> 04:04.680 like your batch, and that has probably more that I don't know. 04:04.680 --> 04:07.680 And it will read those files. 04:07.680 --> 04:09.680 And for each line that it finds in those files, 04:09.680 --> 04:12.680 it will return a record. 04:12.680 --> 04:14.680 And a record looks like this. 04:14.680 --> 04:15.680 Basically a key value. 04:15.680 --> 04:18.680 It will say what host name it came from. 04:18.680 --> 04:20.680 It will tell you the command. 04:20.680 --> 04:24.680 The type of batch interpreter that was identified. 04:24.680 --> 04:27.680 The source file where it was located on the system. 04:27.680 --> 04:31.680 And some other information that is enriched and added to it. 04:31.680 --> 04:35.680 So this is a nutshell how dicec works. 04:35.680 --> 04:39.680 But one history in this case is very specific for the one line 04:39.680 --> 04:40.680 interpreter. 04:40.680 --> 04:44.680 I don't even think it has a Windows counterpart at this moment. 04:44.680 --> 04:46.680 Does it involve version? 04:46.680 --> 04:48.680 Okay, the profile is included. 04:48.680 --> 04:52.680 But if you look at how this boot look like on Python, 04:52.680 --> 04:58.680 you can open a target, which could be all sorts of formats. 04:58.680 --> 05:01.680 My favorite way of developing is actually opening. 05:01.680 --> 05:03.680 If I indicate that's running in like a shared folder, 05:03.680 --> 05:04.680 that's actually running. 05:04.680 --> 05:07.680 So you can open the VMDK and do live, live forensics, 05:07.680 --> 05:09.680 but in a passive way, basically. 05:09.680 --> 05:12.680 And then you just say, well, I'm going to list all the users. 05:12.680 --> 05:16.680 And if I want to show you here is it will parse to container. 05:16.680 --> 05:19.680 And based on what it encounters, it will continue parsing. 05:19.680 --> 05:22.680 So if it is antivS, it will start loading antivS. 05:22.680 --> 05:25.680 And if it then finds Windows, it will load Windows. 05:25.680 --> 05:30.680 And for users on the Windows, it will look at some users, 05:30.680 --> 05:33.680 or profile paths history, profile paths in a registry. 05:33.680 --> 05:36.680 And according to that, it will yield user records. 05:36.680 --> 05:40.680 So based on what I say encounters, it will try to, in a uniform way, 05:40.680 --> 05:43.680 return records that are relevant for you. 05:43.680 --> 05:47.680 And behind this are actually Linux user records. 05:47.680 --> 05:51.680 And Windows user records, but they are combined in the end 05:51.680 --> 05:54.680 in like a generic user records. 05:54.680 --> 05:57.680 And this is how dicex works across the board. 05:57.680 --> 06:00.680 I think this next slide is good for you, makes you explain. 06:00.680 --> 06:03.680 Yeah, so a little bit more in-depth. 06:03.680 --> 06:09.680 I already explained some parts to this, which I'll just go a little bit quickly over it. 06:09.680 --> 06:12.680 dicex basically made up a few core components. 06:12.680 --> 06:18.680 On the bottom, we have like loaders and loaders are anything that kind of like a little 06:18.680 --> 06:21.680 glue layer that can interpret, for example. 06:21.680 --> 06:25.680 From machine metadata, say, for example, you have a virtual machine, 06:25.680 --> 06:28.680 which has like five disks attached to it. 06:28.680 --> 06:31.680 And the Windows event logs are like the third disk. 06:31.680 --> 06:36.680 Then automatically, we can just add that at all of those five disks to kind of like target 06:36.680 --> 06:40.680 and resolve where that, where does the event also store it? 06:40.680 --> 06:45.680 So we don't, there's no manual action needed from the analyst to figure out where the event looks 06:45.680 --> 06:49.680 stored, but also anything like any of your custom formats. 06:49.680 --> 06:54.680 Sometimes we have like a one-off collection script for some kind of like special assignment. 06:54.680 --> 06:58.680 And it's in some non-standard format. 06:58.680 --> 07:05.680 We can use loaders to use some of the dicex APIs to glue together kind of like the state of a system. 07:05.680 --> 07:10.680 So say you have like, you know, the registry hive that you collected through some means like an 07:10.680 --> 07:15.680 or agent maybe and then the event logs you collected through a logical copy for whatever reason 07:15.680 --> 07:18.680 then you conclude them together and a loader. 07:18.680 --> 07:19.680 Next layer is containers. 07:19.680 --> 07:23.680 It's basically anything that looks like a disk image is not much more to it. 07:23.680 --> 07:28.680 And then we just implement most of the comma ones that you'll probably ever encounter. 07:28.680 --> 07:32.680 It's almost like we've volumes, which again, just your regular volumes, 07:32.680 --> 07:37.680 but also things like full volume encryption like Lux and BitLoker. 07:37.680 --> 07:43.680 We support that transparently, so there's no need to wait, you know, like 24 hours for one terabyte drive to unlock. 07:43.680 --> 07:49.680 Using, for example, the target query tool or target shell tool where you can just drop in for like a virtual shelf target. 07:49.680 --> 07:53.680 You can just specify the BitLoker recovery key or the raw BitLoker key or the Lux key. 07:53.680 --> 07:58.680 And you just immediately within a second to drop into like an interactive shelf that system, 07:58.680 --> 08:02.680 purely from like the parsed information from that disk. 08:03.680 --> 08:08.680 Also rate, like automatic rate recovery, basically from Linux rate and Delrate. 08:08.680 --> 08:13.680 We just interpret the metadata, there's no need to manually piece together, you know, how the rate combines. 08:13.680 --> 08:15.680 We just do it for you. 08:15.680 --> 08:22.680 File systems, forced your comma ones, some of your exotic ones as well, but also anything that looks like a file system. 08:22.680 --> 08:27.680 Like is it file, you know, basically a file system, an SMB connection, basically a file system. 08:27.680 --> 08:31.680 Yes, a reverse net called shell, you know, can also be a file system. 08:31.680 --> 08:37.680 You can just, you know, invoke LS and then you get a list directory listing. 08:37.680 --> 08:43.680 And we can piece all of this together into whatever kind of crazy combination you can come up with. 08:43.680 --> 08:51.680 And on top of that, we build kind of like our parsers, like our plugins to interpret or to interact with the target. 08:51.680 --> 08:56.680 So this is your, you know, general artifacts you to think of that you would like to extract from the system. 08:56.680 --> 09:01.680 But also more like very specific stuff to a certain type of system. 09:01.680 --> 09:08.680 So we try to kind of like make an abstraction for anything that all systems usually have. 09:08.680 --> 09:12.680 Like, for example, basically every system that exists has like a host name. 09:12.680 --> 09:14.680 So we provide like a host name plugin. 09:14.680 --> 09:22.680 But for example, for an eZXI hypervisor, we would also like to know what the registered version machines are on that hypervisor. 09:23.680 --> 09:31.680 So in a little bit more of a flashy slide, I would say, a little bit of a recap was what Leonard always talked about. 09:31.680 --> 09:35.680 We have a whole bunch of tools and we just query any artifact we want. 09:35.680 --> 09:42.680 You know, some common ones or, you know, whole bunch of other whatever kind of you can think of. 09:42.680 --> 09:46.680 Again, it's anything which is kind of like the. 09:46.680 --> 09:56.680 The key of dissect, we try to make it as frictionless as possible, you just give it your source data and there's zero kind of like added. 09:56.680 --> 10:01.680 Processing needed to start getting actionable artifacts from your source data. 10:01.680 --> 10:07.680 We want to go from whatever source material you have immediately to. 10:07.680 --> 10:16.680 artifacts, you as an analyst can interpret, so you spend as little time as possible on the boring stuff and as much time as possible actually investigating what matters. 10:16.680 --> 10:20.680 So just, you know, whole bunch of different kind of formats. 10:20.680 --> 10:22.680 Some exotic ones as well. 10:22.680 --> 10:25.680 So we had once and then. 10:25.680 --> 10:30.680 The important thing about dice as well is every artifact we output is kind of like an structured. 10:30.680 --> 10:35.680 It's media format like the key value format Leonard mentioned. 10:35.680 --> 10:41.680 And we can basically, you know, shape this to whatever other format we want. 10:41.680 --> 10:44.680 So you can output it to a JSON file. 10:44.680 --> 10:47.680 CSV can even do it Excel if you want. 10:47.680 --> 10:51.680 But also to, for example, Splunk or Alessic search or Dr. B. 10:51.680 --> 10:56.680 And just immediately start investigating your stuff there. 10:56.680 --> 11:01.680 So this is a little overview of kind of like the different tools we have available within dicec. 11:01.680 --> 11:04.680 A choir is, well, it's acquisition tool. 11:04.680 --> 11:11.680 The fun part about choir is that it uses everything about about dicec to do the acquisition. 11:11.680 --> 11:15.680 So it supports the exact same kind of like. 11:15.680 --> 11:18.680 The exact same target, so the exact same file formats as dicec does. 11:18.680 --> 11:21.680 So it doesn't just work on a live system. 11:21.680 --> 11:24.680 It also works on the VMD case, virtual machines, back up, etc. 11:24.680 --> 11:28.680 So in the case, you have like 90 terabytes of data you want to investigate. 11:28.680 --> 11:30.680 Maybe it's a little bit too much. 11:30.680 --> 11:32.680 You just run a choir against a nine terabytes. 11:32.680 --> 11:35.680 Suddenly you only have a few hundred gigabytes of data to analyze. 11:35.680 --> 11:38.680 It like a cape ish like like format. 11:38.680 --> 11:41.680 Like a lightweight collection package. 11:41.680 --> 11:50.680 And then suddenly you just your amount of data you have to to to to put on your expensive flesh storage, you know, to to quickly analyze that stuff. 11:50.680 --> 11:53.680 It becomes a lot more feasible. 11:54.680 --> 11:57.680 Some like regular common utilities we use. 11:57.680 --> 12:00.680 Some of these are actually community contribute, which is very cool to see. 12:00.680 --> 12:02.680 Like target diff and target info. 12:02.680 --> 12:13.680 And also some more other utility tools that you'll probably use a little bit less, but are also just fun to play around with. 12:13.680 --> 12:16.680 Little microphone dance. 12:16.680 --> 12:22.680 So now we're going to talk a little bit about some of the nesting capabilities of dicec. 12:22.680 --> 12:26.680 But hypervisors or how we call them inside of dicec. 12:26.680 --> 12:27.680 The cold children. 12:27.680 --> 12:31.680 I'm not sure who or why we picked that name. 12:31.680 --> 12:33.680 I don't really know. 12:33.680 --> 12:34.680 A choir. 12:34.680 --> 12:36.680 Children's health and fun. 12:36.680 --> 12:38.680 So what is a. 12:38.680 --> 12:41.680 A child or a sub target. 12:41.680 --> 12:43.680 It's basically what Orioles mentioned. 12:43.680 --> 12:45.680 If you have hypervisor, you have child VMs. 12:45.680 --> 12:48.680 And those VMs you might want to be able to parse. 12:48.680 --> 12:52.680 And maybe you want to do that multiple times. 12:52.680 --> 12:53.680 We use it. 12:53.680 --> 12:54.680 We use dicec a lot. 12:54.680 --> 12:57.680 You build acquisition of data as well. 12:57.680 --> 12:59.680 Like the choir to we mentioned. 12:59.680 --> 13:06.680 We oftentimes run it on the hypervisor to get like a minimal forensic package of all of the sub VMs on the system. 13:06.680 --> 13:09.680 So without having to run code on those systems to acquire data. 13:09.680 --> 13:11.680 We just run it from the hypervisor. 13:11.680 --> 13:15.680 So that is a very useful use case. 13:15.680 --> 13:19.680 And I want to do a small demo on what we use around this. 13:19.680 --> 13:21.680 But first a little bit more of an instruction. 13:21.680 --> 13:26.680 So as said, an example of another multi-layered child is. 13:26.680 --> 13:32.680 For example, a window system running subsystem for Linux. 13:32.680 --> 13:38.680 Which is running Docker, for example, on top of that. 13:38.680 --> 13:46.680 The hypervisor basically transparent to use a user to extend just like all the other layers that Eric explained earlier. 13:46.680 --> 13:50.680 And we currently support actually quite a few hypervisors. 13:50.680 --> 13:52.680 We don't support everything. 13:52.680 --> 13:58.680 But we have parsers for hyperv the various VMware products, virtual box, box, box, 13:58.680 --> 14:00.680 Docker. 14:00.680 --> 14:02.680 And but there are some that we don't support currently. 14:02.680 --> 14:05.680 We don't think we have any sensor for implementation at the moment. 14:05.680 --> 14:08.680 And some container formats we don't fully support yet. 14:08.680 --> 14:13.680 But of course, happy to receive any contributions in that area. 14:13.680 --> 14:16.680 And some hypervisors are making it quite hard to parse things. 14:16.680 --> 14:17.680 Especially VMware. 14:17.680 --> 14:19.680 It's really looking down. 14:19.680 --> 14:22.680 It's management interfaces to execute code. 14:22.680 --> 14:27.680 And I think with TPM it's becoming harder to actually decrypt config files. 14:27.680 --> 14:29.680 That contains some of the file systems. 14:29.680 --> 14:33.680 If you actually want to inspect a ESIX eye machine. 14:33.680 --> 14:36.680 Basically, it makes it quite hard. 14:36.680 --> 14:39.680 So those are sort of like ongoing struggles. 14:39.680 --> 14:41.680 Eric is giving an entire talk. 14:41.680 --> 14:44.680 Actually on the MFS in like an hour or so. 14:44.680 --> 14:48.680 To see what he's been doing his summer holiday. 14:48.680 --> 14:53.680 So child arguments makes a nice for a slide name. 14:53.680 --> 14:56.680 For all the tools that we previously mentioned. 14:56.680 --> 14:59.680 So dark query, target FS, target shell. 14:59.680 --> 15:01.680 Over the last year. 15:01.680 --> 15:09.680 I did some effort to align the functional functionality with shell targets. 15:09.680 --> 15:11.680 Because there were a bit all over place. 15:11.680 --> 15:13.680 Some of the tools supported. 15:13.680 --> 15:16.680 Some of the tools didn't support it or in an unexpected way. 15:16.680 --> 15:18.680 Also at a time. 15:18.680 --> 15:21.680 Dicec didn't really print the shell targets. 15:21.680 --> 15:22.680 It identified. 15:22.680 --> 15:26.680 And that was something I think was very useful as an analyst to be able to see. 15:26.680 --> 15:28.680 Because Dicec did handle parsing of shell data. 15:28.680 --> 15:32.680 But it didn't actually show you as a user. 15:32.680 --> 15:35.680 So that I'll show you some information about that later. 15:35.680 --> 15:37.680 Basically for relevant command name flarks. 15:37.680 --> 15:39.680 Flacks are related to the shell functionality. 15:39.680 --> 15:40.680 It's list children. 15:40.680 --> 15:41.680 Which as a name suggests. 15:41.680 --> 15:43.680 You simply print out what children can find. 15:43.680 --> 15:45.680 The mine mines children. 15:45.680 --> 15:47.680 Actually runs the commands you want to use. 15:47.680 --> 15:49.680 Like the mine's f host name. 15:49.680 --> 15:51.680 For example, it will run on all the children. 15:51.680 --> 15:52.680 It will find. 15:52.680 --> 15:54.680 You can specify specific shell to run things on. 15:54.680 --> 15:57.680 So say you have a hypervisor and you have 100 VMs. 15:57.680 --> 16:00.680 You might only want to run your command on a single machine. 16:00.680 --> 16:01.680 So you can first list all the children. 16:01.680 --> 16:05.680 And then specify a particular VM. 16:05.680 --> 16:07.680 And you can make this recursive. 16:07.680 --> 16:08.680 If you have a lot of time. 16:08.680 --> 16:10.680 Because everything starts getting slower and slower. 16:10.680 --> 16:11.680 More layers you add. 16:11.680 --> 16:14.680 It's a little bit like inception. 16:14.680 --> 16:16.680 Hmm. 16:16.680 --> 16:20.680 So time for a little demo. 16:20.680 --> 16:22.680 One shout out is. 16:22.680 --> 16:24.680 You know, standing on the shoulders of giants. 16:24.680 --> 16:27.680 A lot of these contributions for these various hypervisors came from. 16:27.680 --> 16:29.680 Actually different organizations. 16:29.680 --> 16:30.680 And different people. 16:30.680 --> 16:34.680 So shout out to them for contributing this. 16:34.680 --> 16:36.680 My network has been mainly on. 16:36.680 --> 16:39.680 The high level stuff to align all of the functionality. 16:39.680 --> 16:44.680 So let's run targets query. 16:44.680 --> 16:48.680 We're going to. 16:48.680 --> 16:51.680 Make it quiet so we don't get too much debug information. 16:51.680 --> 16:53.680 We're going to specify virtual box image here. 16:53.680 --> 16:55.680 We're going to list the children that we can find. 16:55.680 --> 16:56.680 These are total level children. 16:56.680 --> 17:01.680 And we can find a singular WSL instance running there. 17:01.680 --> 17:04.680 That we can specify child zero because there's like an index at the front. 17:04.680 --> 17:08.680 And we can print its host name version OS. 17:08.680 --> 17:12.680 You see it's like a galley image. 17:12.680 --> 17:18.680 And you can also run things like command history to see what kind of batch commands were issued, for example. 17:18.680 --> 17:22.680 You get a whole bunch of records back from that. 17:22.680 --> 17:23.680 It's a bit hard to read. 17:23.680 --> 17:29.680 So let's use our dumb to actually only print the command field to make it a little more readable. 17:29.680 --> 17:32.680 And you see here actually some Docker references in my commands. 17:32.680 --> 17:36.680 So let's see there's actually another child in there. 17:36.680 --> 17:39.680 So we're still specifying the first child. 17:39.680 --> 17:44.680 And then we're going to list children again. 17:44.680 --> 17:48.680 And here you'll see that there's actually a Docker running. 17:49.680 --> 17:51.680 But you don't have to do this like multiple times. 17:51.680 --> 17:53.680 You can actually just go to the main image. 17:53.680 --> 17:56.680 Say list children and type recursive. 18:04.680 --> 18:08.680 And here you'll see that you actually have a nested image. 18:08.680 --> 18:12.680 Then you can simply specify this second layer. 18:12.680 --> 18:15.680 And by this one child zero point zero. 18:15.680 --> 18:17.680 And actually again, just run functions on that. 18:17.680 --> 18:19.680 Subsheld. 18:19.680 --> 18:21.680 I was named version OS. 18:21.680 --> 18:24.680 And you can see what has been running there. 18:24.680 --> 18:28.680 This guy's it's a Ubuntu Docker container. 18:28.680 --> 18:33.680 And here again, you can run command history and all the other plugins that were flashing by the screen. 18:33.680 --> 18:35.680 A few slides ago. 18:35.680 --> 18:41.680 But you can also do other commands like printing the users that exist on this system, which is a 18:41.680 --> 18:45.680 very default set of users. 18:45.680 --> 18:50.680 So that's one simple demo of how to interact with the use dissect. 18:50.680 --> 18:55.680 When I first started working on this, I thought, well, how deep and how far can you go with this? 18:55.680 --> 18:57.680 Well, so I wrote a little code. 18:57.680 --> 18:58.680 And it did some effort. 18:58.680 --> 18:59.680 Preparing a demo. 18:59.680 --> 19:03.680 What I'm doing here is actually running on a personal type ofizer. 19:03.680 --> 19:08.680 I'm opening the local target, which is like a magic word to say, or you're running on a target. 19:08.680 --> 19:09.680 Open that target. 19:09.680 --> 19:12.680 And print the six child and print some relevant information. 19:12.680 --> 19:15.680 You actually have the example output record that you would get out of that. 19:15.680 --> 19:21.680 And then recursively start printing the children of that six child. 19:21.680 --> 19:23.680 And then the output that you get. 19:23.680 --> 19:29.680 And this is quite some effort to build actually. 19:29.680 --> 19:30.680 You're going to get parents. 19:30.680 --> 19:31.680 You're going to get a type of hypervizer. 19:31.680 --> 19:33.680 So it's like a box box type ofizer. 19:33.680 --> 19:38.680 Running ESIX eye, running virtual books, running keymer, running hyperv. 19:38.680 --> 19:42.680 Running VML workstation, running VML workstation. 19:42.680 --> 19:48.680 Running virtual books, running WZL, running Docker. 19:48.680 --> 19:50.680 And it's actually alternating as much as possible. 19:50.680 --> 19:51.680 Windows and Linux. 19:51.680 --> 19:52.680 And it's actually Linux. 19:52.680 --> 19:55.680 Windows versions from Windows 11 going back to Windows 7. 19:55.680 --> 19:58.680 Which was quite hard to find the virtual works that you could download. 19:58.680 --> 20:00.680 That's still worked. 20:01.680 --> 20:04.680 And instead of having like a slide. 20:06.680 --> 20:08.680 And there's some relevant names. 20:08.680 --> 20:10.680 Like a VM has like a name. 20:10.680 --> 20:11.680 If you have like your VM list. 20:11.680 --> 20:13.680 And you have of course host names. 20:13.680 --> 20:16.680 So it puts them effort into making sure they were aligned. 20:25.680 --> 20:27.680 So even on the example of saying like great. 20:27.680 --> 20:29.680 The level image is actually in the exact eye host. 20:29.680 --> 20:31.680 And you can't run regaft on that. 20:31.680 --> 20:32.680 Regaft is our registry parser. 20:32.680 --> 20:35.680 Which will recursively print out all of the registry keys. 20:35.680 --> 20:36.680 It finds. 20:36.680 --> 20:39.680 But that of course doesn't have registry because it's a Linux system. 20:39.680 --> 20:41.680 But what you can do is then say mind, mind, mind, 20:41.680 --> 20:44.680 children actually say look for a child that has it. 20:44.680 --> 20:48.680 In this case, I'm limiting to one record for each child that finds. 20:48.680 --> 20:50.680 And you can see that using this. 20:50.680 --> 20:53.680 And actually if you specify to print on the host name and you sort 20:53.680 --> 20:54.680 unique it. 20:55.680 --> 20:58.680 You can see that it will find for each of those host names. 20:58.680 --> 21:00.680 It will find like a million registry keys. 21:00.680 --> 21:02.680 So it is recursively parsing. 21:02.680 --> 21:04.680 As key cinema makes it look very nice. 21:04.680 --> 21:06.680 But this took actually quite a long time on my single host. 21:06.680 --> 21:10.680 Approximo system parsing a million records into dissect multiple times. 21:10.680 --> 21:12.680 Is of course not the fastest. 21:12.680 --> 21:15.680 And then doing the same thing here for the command history. 21:15.680 --> 21:19.680 To actually print like unique host names for which it found. 21:19.680 --> 21:23.680 Yeah, batch history commands within all of those with within all those layers. 21:23.680 --> 21:27.680 And this is roughly how we use dissect to 21:27.680 --> 21:30.680 parse large sets of targets at scale. 21:30.680 --> 21:32.680 We use it for enterprise forensics, 21:32.680 --> 21:34.680 like ransomware case or big breaches, 21:34.680 --> 21:37.680 where we process thousands of systems based on 21:37.680 --> 21:39.680 choir to collect artifacts. 21:39.680 --> 21:41.680 And we run them for all of the plugins. 21:41.680 --> 21:43.680 You can do like minus F wildcard. 21:43.680 --> 21:47.680 I can actually just specify the directory filled with target. 21:47.680 --> 21:49.680 And we scale that up. 21:49.680 --> 21:51.680 That's how we use it. 21:51.680 --> 21:54.680 Back to this. 21:54.680 --> 21:57.680 You're not leaving me much time. 21:57.680 --> 22:01.680 One of the kind of like big pillars around dissect is that we 22:01.680 --> 22:03.680 believe the code is a product. 22:03.680 --> 22:05.680 So we don't just want to see a like to work. 22:05.680 --> 22:07.680 We want the code to be. 22:07.680 --> 22:11.680 Well, it's like like that libraries first class citizen. 22:11.680 --> 22:14.680 And all the CLI tools should just call into the library. 22:14.680 --> 22:18.680 We do this to really promote custom tool development. 22:18.680 --> 22:21.680 But also so it's easy to extend. 22:21.680 --> 22:22.680 Right? 22:22.680 --> 22:26.680 We kind of like develop dissect or architect dissect around 22:26.680 --> 22:28.680 very familiar Python APIs. 22:28.680 --> 22:30.680 So the naming is basically exactly the same. 22:30.680 --> 22:32.680 The arguments are the same. 22:32.680 --> 22:36.680 You maybe just need to like put a little namespace prefix on it 22:36.680 --> 22:38.680 to make it a dissect API. 22:38.680 --> 22:41.680 But kind of the goal we wanted to have is that if you're an analyst, 22:41.680 --> 22:44.680 you know some Python, you know how to write some Python code 22:44.680 --> 22:46.680 to analyze something on your local system. 22:46.680 --> 22:49.680 You can just make it to be able to just like add a few keywords. 22:49.680 --> 22:52.680 Make it a dissect script instead. 22:52.680 --> 22:55.680 And it'll just work against any source data that we support 22:55.680 --> 22:56.680 in dissect. 22:56.680 --> 22:58.680 So instead of just on your local file, just on your local system. 22:58.680 --> 23:00.680 It now works on the family case, 23:00.680 --> 23:01.680 females, 23:01.680 --> 23:02.680 females, 23:02.680 --> 23:03.680 females, 23:03.680 --> 23:04.680 females, 23:04.680 --> 23:07.680 females, and through all the high profiles of layers as well. 23:07.680 --> 23:09.680 However, 23:09.680 --> 23:10.680 it comes to change with this, 23:10.680 --> 23:14.680 which means that we can't just you know blindly merge 23:14.680 --> 23:15.680 every pool quest that we get. 23:15.680 --> 23:18.680 They actually need quite a lot of attention to make sure 23:18.680 --> 23:20.680 that all the code is in consistent quality, 23:20.680 --> 23:22.680 consistent styling, 23:22.680 --> 23:25.680 consistently high level of quality. 23:25.680 --> 23:29.680 The little quick screenshot, 23:29.680 --> 23:31.680 what kind of like a standard interaction or a 23:31.680 --> 23:33.680 injection with a system could look like. 23:33.680 --> 23:34.680 So with target shell, 23:34.680 --> 23:36.680 if you don't specify Python, 23:36.680 --> 23:38.680 you just drop into like a batch like shell. 23:38.680 --> 23:40.680 But with Python, 23:40.680 --> 23:41.680 you know, 23:41.680 --> 23:42.680 well, it's minus p as well. 23:42.680 --> 23:43.680 We call pro mode. 23:43.680 --> 23:45.680 You kind of drop into this Python shell, 23:45.680 --> 23:47.680 and you can interact with the target object, 23:47.680 --> 23:51.680 and you can just interact with it like a regular normal Python object. 23:51.680 --> 23:53.680 But also we want to make it easy. 23:53.680 --> 23:56.680 We don't want to hide any kind of like off the details of 23:56.680 --> 23:57.680 the system, 23:57.680 --> 23:59.680 so we want to make it very easy to drill down 23:59.680 --> 24:02.680 into the lower layers of the target as well. 24:02.680 --> 24:03.680 So we really want to, 24:03.680 --> 24:05.680 we don't want to hide what an eye note looks like, 24:05.680 --> 24:07.680 or what the fields are of an eye note. 24:07.680 --> 24:10.680 We want you to be able to very easily interact with that as well, 24:10.680 --> 24:12.680 and inspect it if necessary. 24:12.680 --> 24:16.680 So we open sourced few years ago, 24:16.680 --> 24:19.680 or kind of like a company model, 24:19.680 --> 24:21.680 it's like four more scarce society. 24:21.680 --> 24:23.680 And we've been you know, 24:23.680 --> 24:26.680 standing again kind of like on the on the shoulders of giants. 24:26.680 --> 24:29.680 We've been using so much open sourced tweeting over there, 24:29.680 --> 24:30.680 know, 24:30.680 --> 24:32.680 the existence of our company. 24:32.680 --> 24:34.680 We feel like it's time to give back as well. 24:34.680 --> 24:35.680 Since we open sourced, 24:35.680 --> 24:38.680 we really see a high adoption rate. 24:38.680 --> 24:40.680 A number of contributors really picking up every, 24:40.680 --> 24:42.680 every time, like every week, 24:42.680 --> 24:44.680 sometimes every month at least we see like, 24:44.680 --> 24:46.680 like a new contributor, for example, or one or two. 24:46.680 --> 24:48.680 And it's all over the place as well. 24:48.680 --> 24:51.680 Like we see some government contributions from our competitors. 24:51.680 --> 24:54.680 I think basically almost every compared to the Netherlands, 24:54.680 --> 24:57.680 use the dissect and most of them also contribute back. 24:57.680 --> 25:00.680 But also students, just random research on the internet, 25:00.680 --> 25:02.680 it's quite nice to see. 25:02.680 --> 25:04.680 And so some incredible, 25:04.680 --> 25:06.680 it's not just like fixing a typo, 25:06.680 --> 25:08.680 you know, like we're fixing a grammar mistake, 25:08.680 --> 25:11.680 so some very high quality contributions we get. 25:11.680 --> 25:14.680 I would have a with open sourcing comes new challenge as well. 25:14.680 --> 25:16.680 Very nice is that, you know, 25:16.680 --> 25:18.680 the rate of finding bugs is a lot higher. 25:18.680 --> 25:19.680 Your exposure is bigger, 25:19.680 --> 25:22.680 but unfortunately the rate of fixing is only, 25:22.680 --> 25:24.680 like slightly higher. 25:24.680 --> 25:26.680 Because again, like I said, 25:26.680 --> 25:28.680 not everyone is also a suitable core contributor. 25:28.680 --> 25:30.680 And the videos, they quite a lot of time. 25:30.680 --> 25:32.680 So we have quite a lot of, 25:32.680 --> 25:34.680 well, open issue with Google Quest as well. 25:34.680 --> 25:37.680 And we just, it's just hard to kind of keep up with, 25:37.680 --> 25:39.680 a bit of flow sometimes. 25:39.680 --> 25:41.680 So if anyone has any chip tricks, 25:41.680 --> 25:42.680 you can find us later, 25:42.680 --> 25:45.680 or maybe we can exchange some ideas. 25:45.680 --> 25:46.680 Actually pretty fun, 25:46.680 --> 25:48.680 the slide from NFI. 25:48.680 --> 25:51.680 We kind of feel a similar, 25:51.680 --> 25:53.680 we kind of have a similar problem as well. 25:53.680 --> 25:56.680 Like we try to push hard on unit testing of all of our parsers. 25:56.680 --> 25:58.680 But unit testing only gets you so far. 25:58.680 --> 26:00.680 It only works like specific versions, 26:00.680 --> 26:03.680 specific stage that you have your just data in at that moment. 26:03.680 --> 26:06.680 And we currently don't really have a nice method to stay up to date 26:06.680 --> 26:08.680 with like operating system updates, 26:08.680 --> 26:10.680 false system updates, stuff like up. 26:10.680 --> 26:13.680 So if anyone's working on this space, 26:13.680 --> 26:15.680 or knows who is working in this space, 26:15.680 --> 26:17.680 please head us up. 26:17.680 --> 26:19.680 Very quickly. 26:19.680 --> 26:21.680 A few community use cases. 26:21.680 --> 26:23.680 We've seen that actually go beyond, 26:23.680 --> 26:24.680 kind of like the forensic, 26:24.680 --> 26:26.680 or incident response use case, 26:26.680 --> 26:28.680 is actor investigation. 26:28.680 --> 26:29.680 It's a skill. 26:29.680 --> 26:30.680 We see this from like, 26:30.680 --> 26:32.680 government institutions, 26:32.680 --> 26:33.680 and law enforcement institutions. 26:33.680 --> 26:35.680 But also OT security and compliance at skill. 26:36.680 --> 26:37.680 Very quickly, 26:37.680 --> 26:39.680 could the actor tracking like, 26:39.680 --> 26:41.680 instead of just, 26:41.680 --> 26:42.680 you know, 26:42.680 --> 26:44.680 trying to investigate a breach. 26:44.680 --> 26:47.680 You can also investigate a system from a 26:47.680 --> 26:48.680 tread actor. 26:48.680 --> 26:51.680 And kind of like use the traces that are available on that 26:51.680 --> 26:52.680 to, 26:52.680 --> 26:53.680 for example, 26:53.680 --> 26:55.680 correlate multiple systems together, 26:55.680 --> 26:56.680 cluster them together, 26:56.680 --> 26:59.680 try to determine what the system 26:59.680 --> 27:00.680 might be used for, 27:00.680 --> 27:03.680 or just keep tabs on what the tread actor is doing. 27:04.680 --> 27:07.680 And some of the key benefits, 27:07.680 --> 27:09.680 we've got them back as feedback from our, 27:09.680 --> 27:10.680 from our, 27:10.680 --> 27:12.680 wouldn't say part of it, 27:12.680 --> 27:13.680 but from our users, I guess, 27:13.680 --> 27:17.680 is that they're really like kind of the approach we've taken with, 27:17.680 --> 27:19.680 kind of like the familiarity around Python, 27:19.680 --> 27:20.680 the same APIs, 27:20.680 --> 27:24.680 and kind of like having a strict output format as well, 27:24.680 --> 27:27.680 instead of having a bunch of different Python scripts that output in, 27:27.680 --> 27:29.680 like a bajillion different formats, 27:29.680 --> 27:32.680 they're not like a centralized knowledge hub 27:32.680 --> 27:36.680 of all of their plugins that work on any current and future source data 27:36.680 --> 27:38.680 that they might encounter. 27:38.680 --> 27:39.680 Similarly, 27:39.680 --> 27:40.680 okay, insights, 27:40.680 --> 27:43.680 someone in the OT world came to us and said, 27:43.680 --> 27:44.680 like, hey, 27:44.680 --> 27:45.680 we actually have a, 27:45.680 --> 27:46.680 like a big problem, 27:46.680 --> 27:50.680 we have a lot of OT systems that we counterrun security software on, 27:50.680 --> 27:54.680 but we still want to get some security insight in there, 27:54.680 --> 27:56.680 also just compliance stuff, 27:56.680 --> 27:57.680 you know, 27:57.680 --> 27:58.680 we're unused, 27:58.680 --> 28:00.680 we're used these sticks, 28:00.680 --> 28:01.680 we're used the wrongly, 28:01.680 --> 28:03.680 and now they can just, 28:03.680 --> 28:04.680 oh, sorry, 28:04.680 --> 28:06.680 current solution was a kind of golf cart, 28:06.680 --> 28:09.680 and the current solution we have is to make backups, 28:09.680 --> 28:10.680 and then they investigate, 28:10.680 --> 28:11.680 dissect, 28:11.680 --> 28:12.680 we're using, 28:12.680 --> 28:13.680 dissect the investigators, 28:13.680 --> 28:14.680 backups, 28:14.680 --> 28:16.680 and extract the same information. 28:16.680 --> 28:19.680 We are out of time, 28:19.680 --> 28:22.680 but basically what I just said, 28:22.680 --> 28:25.680 about centralized repository, 28:25.680 --> 28:27.680 and thank you. 28:27.680 --> 28:29.680 Thank you. 28:29.680 --> 28:31.680 Thank you. 28:31.680 --> 28:33.680 Thank you.