WEBVTT 00:06.940 --> 00:13.760 So, anyways, I'm Dan Burrows, just a little bit about myself. 00:13.760 --> 00:19.200 I'm a professor at the University of Central Florida in the Engineering Technology Department. 00:19.200 --> 00:32.260 Specifically, I work in the Information Systems Technology Program, which is a, it's a very applied approach to engineering and specifically information technology systems. 00:32.260 --> 00:43.040 We're currently at the University of Central Florida, developing a undergraduate security program that I'm also, I'm the one that's mainly involved in developing that. 00:43.040 --> 00:46.640 And that's actually what my second talk a little bit later is on today. 00:46.660 --> 00:51.420 But this is the more, maybe more interesting, more technical one. 00:51.640 --> 00:59.780 My past research includes the correlation of distributed network sensors. 00:59.780 --> 01:16.960 If you have a, if you have a large scale network, you have intrusion detection systems, you have firewalls, you have other things that are recording information saying what's going on on the network, trying to correlate that information together to bring it all together and trying to see the big picture of what's going on, 01:16.960 --> 01:23.020 rather than getting these little kind of half views of what's really occurring out on the network. 01:23.020 --> 01:31.100 And also I'm working on some projects that involve combined data sharing networks for law enforcement in the state of Florida. 01:32.540 --> 01:37.480 You know, this little blurb ad about the University of Central Florida, it's down in Orlando, Florida. 01:37.480 --> 01:42.240 It's about, we've got about 42,000 students there, about 5,500 of which are in engineering. 01:42.280 --> 01:46.740 We're located about 13 miles east of Orlando, Florida. 01:48.480 --> 01:54.740 As I said, the Information System Technology Program, this is a really, it's an applied engineering degree. 01:54.740 --> 02:02.620 It's very hands on, very real world, very current tools, not so much the traditional theoretical approach to engineering. 02:03.700 --> 02:07.220 Heavy concentration on hands on learning in the program. 02:08.320 --> 02:19.040 A little bit about the background of what led me to this current idea is, there was a previous research that I worked on. 02:19.040 --> 02:37.200 I gave a couple of presentations back at DEF CON 9 and 10, and this was on using Bayesian multiple hypothesis to try and analyze reports from these distributed intrusion detection systems and other types of network sensors, with the idea of trying to determine if what you were seeing were correlated events, 02:37.200 --> 02:48.100 if this was an initial attack and a follow-up, or if the two events you were seeing in two different places might be two systems communicating who shouldn't be communicating together. 02:48.100 --> 02:54.040 And to try and use multiple sensors to distribute over large distributed networks to try and do this. 02:54.040 --> 03:13.600 The basic idea behind what I was doing with that was taking target tracking methods that came out of, actually out of radar target tracking systems, trying to track real objects in the sky with various radar systems, and taking that same approach and treating all of our sensors that we have on our network, 03:13.600 --> 03:23.040 whether it's an IDS, a firewall, a router, even a human, sat there making observations about what's going on, and trying to automate the correlation of that together. 03:23.040 --> 03:36.580 And this wasn't intended to totally throw the human analyst out of the loop, but just to kind of act as a sort of a first level filtering system to throw away a lot of the information that you don't need in order to come to a conclusion about what's going on, 03:36.580 --> 03:41.960 with the idea that we were going to kind of move this more towards a point of view. 03:41.960 --> 03:48.340 Instead of looking at this one section of the network or this one part of what was going on that's visible to this one sensor. 03:48.340 --> 03:52.260 Like, you know, you've got your firewall sat at the, say you've got it sat at the border of your network. 03:52.260 --> 03:53.020 It sees everything that's going on. 03:53.040 --> 03:54.480 It sees everything that's coming in and out of the border. 03:54.480 --> 03:57.240 But it doesn't see stuff that's entirely internal to the network. 03:57.320 --> 04:04.400 You might have an intrusion detection system sat on one segment of the network that sees what's going on there, but it doesn't see what's going on on another segment of the network. 04:04.400 --> 04:13.820 And to take all these little pictures, pieces of information, and to put them together to get a more complete view of what someone was doing while they were attacking the network. 04:13.840 --> 04:21.440 And did this through using radar tracking algorithms, specifically Bayesian multiple hypothesis tracking. 04:22.740 --> 04:34.580 And making an analogy to the world of computer security where our firewalls, our IDS, our humans looking at what's going on on the network, anything that records information is a sensor. 04:34.580 --> 04:36.100 That's like a radar system. 04:36.180 --> 04:41.820 The actions that the person out there trying to break into the network are doing, that's the target. 04:41.820 --> 04:43.480 And that's the trace they leave behind. 04:43.480 --> 04:45.880 And we're trying to put these traces together. 04:45.980 --> 04:49.400 And we're working in a situation where we've got to do this in real time. 04:49.400 --> 04:50.920 We've got incomplete data. 04:50.920 --> 04:56.100 We've got inaccurate data, potentially, about what's going on, depending on how your sensors are operating. 04:57.620 --> 05:02.600 Just a little bit more about the system. 05:03.320 --> 05:16.080 The idea, how this works, this idea of this multiple hypothesis tracking is as events occur on the network, as an event is when a sensor recognizes that something's occurring. 05:16.080 --> 05:30.700 When something actually pops up on the sensor, when it gives a report, when you've got an IDS that tells you, hey, I think I see something, when you've got a firewall that decides it's not going to allow this packet or it sees something unusual, when you've got your sysadmin on your network saying, 05:30.700 --> 05:32.880 hey, you know, something weird's going on here. 05:32.880 --> 05:35.940 As these events arrive, they're analyzed. 05:35.940 --> 05:41.500 And say, for example, we're sat there and one of our systems sees a port scan happening out there. 05:41.780 --> 05:45.720 We build a hypothesis about what we think's going on. 05:45.720 --> 05:52.960 In this case, if we've got a single scan coming in from the outside world, hey, you know, that's all the information we have. 05:52.960 --> 05:56.960 That's the only hypothesis we can come to is that that's what's going on. 05:56.960 --> 05:58.960 We're seeing a port scan right now. 05:59.260 --> 06:03.060 Really, I guess, actually, technically, you can make two hypotheses at this point. 06:03.060 --> 06:11.200 You can say, hey, there's a port scan going on, or alternatively, my IDS isn't working properly, and this is a false positive. 06:12.560 --> 06:18.500 Then, as other events occur, say you see a buffer overflow attack against a machine following that. 06:18.500 --> 06:21.080 Well, what could be going on now? 06:21.080 --> 06:26.280 We could make the assumption that the port scan is being followed up by a buffer overflow. 06:26.280 --> 06:30.960 Someone scanned a machine for a vulnerability, then they attacked that particular vulnerability on it. 06:30.960 --> 06:43.000 Or, potentially, these could be two unrelated events, that the port scan could be part of one attack, the buffer overflow could be part of a different attack on the system. 06:44.640 --> 06:49.940 And what we were trying to do with this system was trying to automate the process of figuring these out. 06:49.940 --> 06:52.400 Now, this is a simple example. 06:52.400 --> 06:54.280 This is a pretty trivial case. 06:54.360 --> 07:09.200 In this particular case, if the port scan is a scan against, I don't know, against port 80, and the buffer overflow is a buffer overflow against an IIS server, chances are those two things are related. 07:09.200 --> 07:14.240 If the port scan doesn't match up with what the buffer overflow was, chances are they're not related. 07:14.240 --> 07:31.660 But, you can extrapolate from this idea into much more complicated systems and much more complicated series of events, of trying to piece together the pieces and figure out whether or not all of these events and all of these things that we see occurring across the network are related together, 07:31.660 --> 07:43.800 are they not related together, are they likely to be something real, are they likely to be a false positive caused by a imperfect sensor, imperfect IDS, or firewall, or human in the loop. 07:45.720 --> 07:53.920 Actually, when I was working on this, one of the most interesting sources of data that I had to work with came from the Capture the Flag games here at DEF CON. 07:53.920 --> 07:58.740 Luckily, the SHMOO group captures all of that data that goes on during the Capture the Flag game. 07:58.740 --> 08:00.540 They capture all of that network traffic. 08:00.820 --> 08:08.200 And that provided a great playground to work in, to try and see if that information could be correlated together. 08:08.240 --> 08:12.040 And this little graph I got up here, I mean, this is kind of just pulled right out of context. 08:12.040 --> 08:19.240 These are some slides I grabbed just to give a bit of background about the previous research in this. 08:20.400 --> 08:42.020 Basically, what this was showing is, as you let the number of hypotheses that you consider increase, in that previous example, I said that we had the two hypotheses, either these two events are unrelated, or these two events are part of a chain of a single attack. 08:42.680 --> 08:45.860 Well, we let those, we say, these are our two hypotheses. 08:45.860 --> 08:54.220 And then we look at the evidence that's going on, and we evaluate them, and we find out which hypotheses we think is currently the best one we have available. 08:54.640 --> 08:57.740 Then, we wait for more information to come in. 08:57.740 --> 09:02.060 We'll have a certain confidence level, and how confident do we believe in this hypothesis? 09:02.760 --> 09:11.760 As more information comes in, we'll build more hypotheses, and we re-evaluate the likelihood of our existing hypotheses. 09:11.760 --> 09:23.020 Eventually, at least in theory, this will eventually converge to a point where one hypothesis is clearly the winning hypothesis. 09:23.120 --> 09:34.940 Now, the problem with it, I said that's in theory, the problem with that is, you have to consider every possible hypothesis in order to do that, and the number of hypotheses grows at a super-exponential rate. 09:34.940 --> 09:37.340 So, it's practically impossible to do that. 09:37.340 --> 09:42.580 There's a lot of work on the pruning of them, deciding which ones you want to keep, which ones you want to throw away. 09:42.700 --> 09:58.820 And what this graph is just showing here was, along the bottom is a number of hypotheses that were allowed to remain in the system, going from, well, at the bottom one, all the way up to 1,000, and the accuracy of how well it correlated the different attacks together. 09:58.820 --> 10:12.040 And it never quite got up to 100%, but it got up into about 93, 94% accuracy on the capture-the-flag data, being able to piece together what we're seeing and what were related attacks. 10:12.040 --> 10:29.820 And now, of course, this was actually correlated against the baseline, was done by hand, taking, we, I, and a few others that helped me, took the data over the capture-the-flag game over about a, I think it was about an eight-hour period, and by hand, 10:29.820 --> 10:37.460 figured out what was related information, what were related attacks, and then built a system that could do to automate that process. 10:37.560 --> 10:40.060 So, this thing, it worked. 10:40.060 --> 10:42.540 This is a, it was a pretty decent idea. 10:42.540 --> 10:43.420 It worked. 10:43.420 --> 10:47.020 It didn't necessarily work as well as we had hoped, initially. 10:48.500 --> 10:55.620 If you've got everything on a same network or related network, where you're likely to see lots of related events, it works well. 10:55.660 --> 11:10.040 If you've got this distributed over large networks, where you're likely to see many more unrelated events than related events, it goes, the accuracy goes down a bit, or at least the amount of work you have to do to get good accuracy goes way up, is more accurate. 11:12.440 --> 11:15.840 So, that's what it had done in the past. 11:16.240 --> 11:25.800 And this got me thinking about, so, this was a system that had developed to try and detect related information on a network. 11:25.840 --> 11:29.120 And then, of course, you know, once you can do that, you always think about the next step. 11:29.120 --> 11:34.680 And once the next step, once you can detect something, you figure out how to hide it even better, right? 11:34.680 --> 11:38.180 You know, it's always kind of that one-upmanship game that we're playing. 11:38.180 --> 11:42.780 So, it got me thinking, how do we defeat a system that works like that? 11:42.780 --> 11:59.520 How could you avoid detection on a network that was well-observed, well-monitored, and where the information was well-correlated, where you couldn't rely on the guy sat over on this part of the network not knowing what the guy sat over on this other part of the network was doing, 11:59.520 --> 12:02.060 or seeing, or knew about what was going on. 12:02.060 --> 12:08.060 If you assume that there was complete coverage of the network, how could you hide what was going on on there? 12:08.060 --> 12:23.120 And I'm not necessarily, I'm not talking about so much the detection of a specific attack, like someone does a buffer overflow against a web server, they do, you know, whatever other type of initial attack to gain access to the system. 12:23.120 --> 12:29.360 But assuming they're already on there, they've got on to the system and they want to keep communicating back and forth. 12:29.360 --> 12:33.140 They've got their remote machine they're sat at. 12:33.140 --> 12:35.140 They've got access to a machine on the network. 12:35.140 --> 12:38.040 They want to communicate back and forth, but they don't want to be detected while they're on the network. 12:39.760 --> 12:44.540 How could you go about that and avoid detection on a well-monitored network? 12:46.460 --> 12:51.460 So, you have to look at this from the point of view of where do we have the choices about what we do? 12:51.700 --> 12:55.840 When you're talking about the initial attack, you don't have a whole lot of choices. 12:56.040 --> 13:03.400 If you've got a, you know, I guess, I mean, I guess, unless you get lucky and you see a system out there that's got a ton of vulnerabilities on it, then you've got some choice about what to do. 13:03.400 --> 13:07.880 But assume that you have limited choices of how a system is broken into. 13:07.880 --> 13:10.480 There's limited ways into the system to begin with. 13:10.480 --> 13:12.300 You don't have many choices there. 13:12.640 --> 13:21.680 So, any tool that's written to, to initially gain access to a system usually has a fairly limited life span. 13:21.680 --> 13:27.980 At least it's limited, limited life span in the realm of people who actually care about security. 13:27.980 --> 13:33.220 You always find some bozo out there who never updates anything, never puts any security on their system. 13:33.220 --> 13:34.540 You can always get into them. 13:34.540 --> 13:37.860 But talking about the people who are serious about it, you have a limited life span. 13:37.880 --> 13:40.540 With any sort of tool for initially getting in there. 13:41.460 --> 13:48.560 However, once you have access to a machine and all you're worried about doing is communicating with that machine, you've got a lot of choices. 13:48.680 --> 13:51.400 You know, we're not stuck with one type of communication protocol. 13:51.400 --> 13:56.080 We're not stuck with any traditional communication protocol that's out there whatsoever. 13:57.540 --> 14:03.800 The trick to this is figuring out which ones work and which ones won't be seen. 14:07.960 --> 14:09.740 So, here's, here's the question. 14:09.740 --> 14:13.320 How do you communicate on a network without letting anyone know you're doing it? 14:13.820 --> 14:15.280 First thing's first. 14:16.620 --> 14:18.860 How do they detect what's going on? 14:18.860 --> 14:21.960 How does someone see what you're doing on a network? 14:21.980 --> 14:24.880 You've got IDS, you've got firewalls, you've got observers. 14:24.920 --> 14:29.320 All of these things are sat there looking at what's going on on the network. 14:30.980 --> 14:42.440 In general, I pick the IDS and I say software human because, you know, whatever's looking at your network, whether it's automated or whether it's a person, they're trying to determine if someone's intruding on your network. 14:42.980 --> 14:44.420 You get two basic forms of this. 14:44.420 --> 14:58.500 And this, this applies, um, I think the IDS system in at least one sense is the most general case and you can kind of, uh, find derivative cases that cover this, the same concept for firewalls and routers and everything else out there. 14:58.500 --> 15:00.920 There's basically two forms of detection out there. 15:01.000 --> 15:02.860 Anomaly and signature detection. 15:03.060 --> 15:06.620 Signature detection works on known attacks, known events. 15:06.620 --> 15:13.460 You know, if you, if you know exactly what you're looking for, you know, you see this packet go by, it's something bad, you want to throw up an alert about it. 15:13.460 --> 15:19.000 Hey, that's great, you can catch it every time, it'll never get by, you know, you've got that one nailed. 15:19.500 --> 15:29.020 The only way to avoid that type of detection is to use either an unknown method or something perhaps that changes constantly, never use the same method twice. 15:30.580 --> 15:37.800 The anomaly detection, it doesn't detect misuse of the system, it doesn't detect something malicious, it just detects something unusual. 15:37.800 --> 15:48.580 So, it's, it's not necessarily really great at trying to pick up something bad happening on your network, but it'll pick up something unusual. 15:48.820 --> 15:55.040 And it's really, if the signature detection doesn't work, that's the only chance you have left, is looking for something unusual. 15:55.040 --> 15:58.420 If you don't know what to look for, you've got to look for things that stand out. 15:59.500 --> 16:03.500 So, we can't really avoid the signature detection. 16:03.500 --> 16:10.160 If you've got a way of communicating or a way of doing anything on the network and someone can write a signature to detect that, that's it. 16:10.160 --> 16:12.080 You can't, you can't do anything with it. 16:12.080 --> 16:15.580 It's got a limited lifespan, eventually it's going to be seen. 16:17.200 --> 16:32.600 So, the only alternative is to use something that you can't write a signature for, something that changes constantly, something that is quote unquote random, or at least appears random to anything that's observing the network. 16:32.720 --> 16:36.760 And we have to be able to do this without looking unusual. 16:36.780 --> 16:37.760 And that's the key. 16:37.760 --> 16:49.880 Not only do we have to do something, it's kind of a catch-22 in a way, because we've got to do something that's very unusual, you know, this kind of random changing communication protocol, but we've got to do it without looking unusual. 16:49.880 --> 16:52.580 You can't stand out on there. 16:52.580 --> 16:57.280 So, the first stage of this is to detect the baseline of the network. 16:57.480 --> 17:01.640 What does the traffic on the network look like to begin with? 17:01.640 --> 17:04.420 What does, what is occurring on the network? 17:04.420 --> 17:06.760 What happens out there all the time? 17:06.780 --> 17:08.700 And this can be done passively. 17:08.700 --> 17:24.660 You can sit back and discover what type of traffic is allowed on the network, what does normal traffic look like, and kind of build yourself a map of both what is going on on the network, what the structure of the network is, and what's allowed in and out of this network. 17:26.140 --> 17:28.000 This is not a new concept. 17:28.180 --> 17:30.160 This just, this general idea of doing this. 17:30.160 --> 17:31.240 This is done all the time. 17:31.240 --> 17:36.760 This is how many tools and, and other fun little things are used. 17:36.780 --> 17:38.020 They're written and developed. 17:38.040 --> 17:46.140 But the key thing is, is that this is what, generally, this is what people, people do this process. 17:46.200 --> 17:50.380 Someone looks at a network or you think about what's going on on the network. 17:50.640 --> 17:53.200 You know, a good example of this is a reverse WWW shell. 17:53.200 --> 17:54.740 That's an old tool. 17:54.740 --> 17:59.060 The idea of this was that you've got a computer inside the network. 17:59.660 --> 18:02.780 It's, you're not allowed to make connections from the outside to it. 18:02.780 --> 18:06.720 You know, the firewall's gonna drop any connection, inbound connections to it. 18:06.780 --> 18:09.780 So you put a piece of software on that computer inside the network. 18:09.860 --> 18:15.480 That, at certain intervals, perhaps at random intervals, it looks like it's going out to a web browser. 18:15.480 --> 18:17.100 It goes, makes a web request. 18:17.100 --> 18:25.960 Except that, what that web request is doing is coming to your computer on the outside, getting the next command that you've told, told it to do. 18:25.960 --> 18:33.900 It carries it back as the HTTP response to the, to the target computer, to the one that, the one that you got access to. 18:33.900 --> 18:36.160 And then it carries out that particular command. 18:36.160 --> 18:36.760 It's masquerade. 18:36.780 --> 18:40.400 It's masqueraded looking like the, the computer on the inside is just surfing the web. 18:40.840 --> 18:44.160 That's a great way of hiding it, unless someone knows to look for it. 18:44.160 --> 18:49.540 Once someone knows to look for it, if you stick with it too long, they're gonna look for it, they're gonna see it, it's gonna stand out. 18:50.380 --> 18:56.820 Similarly, carrying data commands and ICMP echo, echo response packets, same sort of, same sort of idea. 18:57.160 --> 19:10.140 What I'm trying to do with this project is to automate this process and make it run on the fly and may, and have it adapt itself to whatever network it's currently working on. 19:10.140 --> 19:17.300 Look at what's going on on the network, decide what to do on the network, decide what will work there, and then carry it out. 19:19.220 --> 19:26.580 So, some aspects of network traffic are gonna have a low entropy, meaning a very low randomness. 19:26.580 --> 19:31.680 They're gonna be very kind of, the same thing's always gonna happen. 19:31.680 --> 19:35.240 Certain communication protocols are only gonna go to certain computers. 19:35.280 --> 19:37.780 DNS requests are only gonna go to your DNS servers. 19:37.780 --> 19:40.280 They're not gonna be jumping around to every computer on your network. 19:40.860 --> 19:43.700 Incoming web requests are probably only gonna come to your web server. 19:43.700 --> 19:45.720 They're not gonna come to every computer on your network. 19:46.020 --> 19:48.980 Other things are gonna look much more random. 19:48.980 --> 19:56.540 Maybe outgoing web requests, you know, people, different people surfing the web, outgoing FTP, all, all sorts of things. 19:56.540 --> 19:58.300 Other things are gonna be very random. 19:58.300 --> 20:00.460 There's gonna be a lot more entropy in that. 20:01.100 --> 20:05.400 And entropy is the key to hiding information. 20:05.740 --> 20:12.720 The, the more entropy you have on the system, the more information you can hide in that. 20:12.720 --> 20:22.080 This is like if you look at, if you look at steganography, for example, you know, you're trying to hide information in something else. 20:22.080 --> 20:28.940 If you've got a bitmap, a bitmap has lots and lots of redundant information in it, versus a JPEG image. 20:28.940 --> 20:33.700 A JPEG has taken a lot of that redundant information, that's why a JPEG's smaller than a bitmap. 20:33.860 --> 20:37.280 You can hide a lot more information than a bitmap than you can in a JPEG. 20:37.280 --> 20:40.220 Higher entropy, you can hide more information inside it. 20:40.320 --> 20:51.040 So, if we find what has the highest entropy on that network, what communication channels have the highest degree of randomness, we can then pick what we want to work in. 20:51.040 --> 20:54.980 And we've got all sorts of, all sorts of things that we can work with here. 20:54.980 --> 21:03.860 We can work with the timing of the packets, we can work with packets, sending out packets that have bad checksums, malicious checksums, malformed checksums, all sorts of different things that we can play with. 21:03.860 --> 21:10.180 We don't have to use a SSH or a Telnet or some other standard type of communication format. 21:10.180 --> 21:18.040 We can send crafted packets where the information is carried in all sorts of the different little pieces of information inside that packet. 21:18.040 --> 21:23.360 The key is, we just have to make sure it doesn't look unusual when that packet goes out. 21:23.680 --> 21:28.780 So the overall concept here is we detect what the network baseline condition is. 21:28.780 --> 21:33.060 On the specific network that we're looking at, what does normal look like? 21:33.060 --> 21:34.680 What doesn't look unusual? 21:35.040 --> 21:38.820 And then select from that the potential communication channels. 21:38.960 --> 21:43.480 Determine which ones have highly random information on the network. 21:43.640 --> 21:47.880 Trim it down, figure, we've got, initially we can select from anything. 21:47.880 --> 21:50.440 We can craft a packet that does anything we want. 21:50.440 --> 21:58.400 We're going to look at what happens on the network, figure out what's allowed, limit it to that, and then limit it to what has a lot of entropy within that. 21:58.780 --> 22:02.380 And then we have to somehow communicate this method to the receiver on the outside. 22:02.380 --> 22:07.020 We have to get the information of what communication scheme we're going to use. 22:07.020 --> 22:09.340 We have to get that to the receiver outside. 22:09.340 --> 22:13.800 And then maintain a, you know, I put almost undetectable presence on the network. 22:13.920 --> 22:15.900 You never should think you're undetectable. 22:15.900 --> 22:18.140 You should never think anything's absolute, because it never is. 22:18.140 --> 22:20.020 That's how you always get yourself into trouble. 22:20.300 --> 22:24.520 But we can monitor and update the network conditions to stay hidden. 22:24.520 --> 22:28.400 If network conditions change, we can change the scheme we're using to communicate. 22:30.240 --> 22:35.320 On the network, if we just sit there and listen, what can we learn by listening on the network? 22:35.320 --> 22:43.780 There's all sorts of things that we can find out by just sitting there and listening, not doing anything active, not doing anything to be discovered. 22:43.780 --> 22:48.820 You can figure out what types of packets are allowed inside the network, what types of packets are allowed outside the network. 22:48.820 --> 22:51.060 We can figure out the architecture of the network. 22:51.060 --> 22:51.940 Where are the switches? 22:51.940 --> 22:53.060 Where are the routers? 22:53.060 --> 22:55.420 Where are other machines on this network? 22:55.540 --> 22:58.640 And then look at what types of packets are flying around. 22:58.640 --> 23:01.920 What types of packets does the machine that I'm on send and receive? 23:01.920 --> 23:05.000 What types of packets do other machines out there send and receive? 23:05.000 --> 23:21.640 And from this, get an idea of what is allowed to move around this network, what is moving around this network, and what we can inject into the data flowing around without being, without sticking out like a sore thumb and being immediately identified. 23:22.800 --> 23:28.360 So if we narrow down these choices, we start with the ability to send any type of packet, you know, send it to any port whatsoever. 23:28.640 --> 23:45.180 We start paring it down based on what's available, figure out what has the highest entropy, look at this, look at the type of packets based on the protocol, the ports they're using, et cetera, and look at the entropy based on how often do these packets fly, 23:45.180 --> 23:55.660 how different is the data in these packets whenever they go by, what different machines do these types of packets go to, and then pick a channel that we know we can get from point A to point B. 23:55.660 --> 24:05.500 We can get from inside the network, we've got access to the machine network, out of that network over to the place where we want to get the information to, or back and forth, vice versa, either way. 24:05.500 --> 24:11.080 We can figure out what can get into one, out of one network, into another, and then back the other way. 24:11.080 --> 24:13.920 It doesn't necessarily have to be a symmetric communication channel. 24:13.980 --> 24:21.140 The packets that you send out, the packets that you send going out one way, don't have to look a heck of a lot like the packets coming back in the other way. 24:21.160 --> 24:37.700 As long as they're getting to the right segment on the network, as long as they're getting down to the right branch off of your switch so that it can be picked up by a, by a network card in promiscuous mode, as long as you can get down that far and you know what to look for, 24:37.700 --> 24:42.980 each guy on each end knows what to look for, you don't have to have it even be a symmetric communication channel between them. 24:42.980 --> 24:47.040 You can have essentially two different channels going back and forth. 24:49.040 --> 24:55.380 One of the big challenges with this system is starting the conversation. 24:55.380 --> 25:09.220 If you've got a piece of software running on the inside of this network and it's gonna start communicating with you on the outside and you don't know what particular communication scheme it's gonna be using, there's some difficulties in getting, in getting that first packet out of there, 25:09.220 --> 25:15.780 that first piece of information to the outside without having it be something that can easily be written as a signature. 25:15.780 --> 25:23.760 Because it's hard to, it's hard to change things or inject randomness into the first bit of communication. 25:23.760 --> 25:39.700 There's some, there's some ways that we can limit how signature vulnerable that first bit of communication is, but that's one of, that is, that's one of the points that needs, that presents some challenge and needs some work on in this. 25:40.420 --> 25:52.020 Having the communication software itself remain undetected on the remote machine, not talking about what the software is doing, but actually having the software itself avoid detection, of course that's another challenge, but that's a completely different story. 25:52.900 --> 26:03.400 That's, whether it's something that's using a polymorphic code, that is, that changes from one installation to another, or even changes itself constantly. 26:03.400 --> 26:07.960 There are ways around that, but it is a different, but it is another challenge in there. 26:08.300 --> 26:13.780 The third one, that's actually I think a fairly interesting one, is the problem on a low entropy network. 26:13.820 --> 26:17.540 What do you do when there's not a whole lot of randomness going on on the network? 26:18.000 --> 26:22.000 You know, if there's not a lot of randomness in the packets, how do we stay hidden in it? 26:22.020 --> 26:38.500 We have to ensure that every packet that we send out doesn't significantly affect the statistical baseline of the network, so that an anomaly detection system sat on the network will not recognize this as something unusual. 26:38.500 --> 26:39.560 It will not stand out. 26:39.560 --> 26:48.080 It won't push the statistical analysis of the network beyond the limits, beyond the thresholds that we currently have, and it will avoid becoming an anomaly. 26:48.080 --> 27:05.420 This is actually the area right now that I'm doing, concentrating on, trying to figure out the best methods for communicating and picking channels, and picking well-hidden channels on a low entropy network. 27:05.540 --> 27:25.880 So, just as a summary in the system, you know, what's real, what's not real, so far the allowed protocols discovery, the network architecture discovery, the statistical profiling of the network, those are, those are working prototypes. 27:25.880 --> 27:28.920 Those modules, those parts of the system are working prototypes. 27:28.920 --> 27:39.740 Next stages that we're moving towards are the selection of the communication scheme, implementation of the communication, and the adaptation to changing network conditions. 27:39.920 --> 27:50.180 I hope that by this time next year this will actually be a working package that I can give maybe a bit better presentation and demonstration of what it's actually doing. 27:50.180 --> 27:51.200 But this is the current idea. 27:51.980 --> 27:59.540 Anybody that has any interest in this, or any ideas, or feedback, or wants to tell me why I'm crazy for thinking this, feel free. 27:59.540 --> 28:01.260 There's my contact information. 28:02.300 --> 28:05.780 And that's it for a, about a 25-minute presentation. 28:13.260 --> 28:14.520 There's one question. 28:23.990 --> 28:26.430 That, that's a, that is a great question. 28:26.870 --> 28:29.730 I'll tell you, I'll take that just, I'll try and answer one more real quick. 28:29.730 --> 28:39.850 He asked, is there any concept of trying to actually change the baseline of the network so that you can do something that used to look unusual, make it not look unusual anymore? 28:39.850 --> 28:43.570 That is, it's not one of the first-level items on there. 28:43.570 --> 28:45.870 That's a pretty advanced way of working it. 28:45.870 --> 28:56.730 But actually changing, injecting stuff in slow enough that the system, the anomaly detection system adapts to it and thinks that's normal, that is one of the long-term ideas on there. 28:56.730 --> 29:00.210 That's a great idea to put into this. 29:00.210 --> 29:02.490 So, that's 29:36.500 --> 29:38.160 fair enough. 29:38.400 --> 29:40.160 Thank you. 29:42.370 --> 29:43.330 Sorry.