[00:06.940 --> 00:13.760]  So, anyways, I'm Dan Burrows, just a little bit about myself.
[00:13.760 --> 00:16.440]  I'm a professor at the University of Central Florida
[00:16.440 --> 00:19.200]  in the Engineering Technology Department.
[00:19.200 --> 00:23.500]  Specifically, I work in the Information Systems Technology Program,
[00:23.500 --> 00:27.720]  which is a, it's a very applied approach to engineering
[00:27.720 --> 00:32.260]  and specifically information technology systems.
[00:32.260 --> 00:34.360]  We're currently at the University of Central Florida,
[00:34.380 --> 00:40.260]  developing a undergraduate security program that I'm also,
[00:40.260 --> 00:43.040]  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:54.500]  My past research includes the correlation
[00:54.500 --> 00:59.780]  of distributed network sensors.
[00:59.780 --> 01:04.240]  If you have a, if you have a large scale network, you have intrusion
[01:04.240 --> 01:08.140]  detection systems, you have firewalls, you have other things
[01:08.140 --> 01:10.780]  that are recording information saying what's going on on the network,
[01:10.780 --> 01:14.560]  trying to correlate that information together to bring it all together
[01:14.560 --> 01:16.960]  and trying to see the big picture of what's going on,
[01:16.960 --> 01:20.660]  rather than getting these little kind of half views
[01:20.660 --> 01:23.020]  of what's really occurring out on the network.
[01:23.020 --> 01:27.360]  And also I'm working on some projects that involve combined data sharing
[01:27.360 --> 01:31.100]  networks for law enforcement in the state of Florida.
[01:32.540 --> 01:36.440]  You know, this little blurb ad about the University of Central Florida,
[01:36.440 --> 01:37.480]  it's down in Orlando, Florida.
[01:37.480 --> 01:39.900]  It's about, we've got about 42,000 students there,
[01:39.900 --> 01:42.240]  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:51.680]  As I said, the Information System Technology Program,
[01:51.680 --> 01:54.740]  this is a really, it's an applied engineering degree.
[01:54.740 --> 01:58.620]  It's very hands on, very real world, very current tools,
[01:58.620 --> 02:02.620]  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:16.500]  A little bit about the background of what led me to this current idea is,
[02:16.500 --> 02:19.040]  there was a previous research that I worked on.
[02:19.040 --> 02:22.640]  I gave a couple of presentations back at DEF CON 9 and 10,
[02:22.640 --> 02:27.180]  and this was on using Bayesian multiple hypothesis to try
[02:27.180 --> 02:30.500]  and analyze reports from these distributed intrusion detection systems
[02:30.500 --> 02:33.920]  and other types of network sensors, with the idea of trying to determine
[02:33.920 --> 02:37.200]  if what you were seeing were correlated events,
[02:37.200 --> 02:40.800]  if this was an initial attack and a follow-up,
[02:40.800 --> 02:42.760]  or if the two events you were seeing
[02:42.760 --> 02:46.020]  in two different places might be two systems communicating
[02:46.020 --> 02:48.100]  who shouldn't be communicating together.
[02:48.100 --> 02:50.480]  And to try and use multiple sensors to distribute
[02:50.480 --> 02:54.040]  over large distributed networks to try and do this.
[02:54.040 --> 02:59.980]  The basic idea behind what I was doing with that was taking target tracking methods
[02:59.980 --> 03:05.120]  that came out of, actually out of radar target tracking systems,
[03:05.120 --> 03:09.540]  trying to track real objects in the sky with various radar systems,
[03:09.540 --> 03:12.600]  and taking that same approach and treating all of our sensors
[03:12.600 --> 03:16.160]  that we have on our network, whether it's an IDS, a firewall, a router,
[03:16.160 --> 03:20.300]  even a human, sat there making observations about what's going on,
[03:20.300 --> 03:23.040]  and trying to automate the correlation of that together.
[03:23.040 --> 03:26.600]  And this wasn't intended to totally throw the human analyst out of the loop,
[03:26.600 --> 03:29.720]  but just to kind of act as a sort of a first level filtering system
[03:29.720 --> 03:34.020]  to throw away a lot of the information that you don't need in order
[03:34.020 --> 03:38.020]  to come to a conclusion about what's going on, with the idea
[03:38.020 --> 03:41.960]  that we were going to kind of move this more towards a point of view.
[03:41.960 --> 03:45.480]  Instead of looking at this one section of the network or this one part
[03:45.480 --> 03:48.340]  of what was going on that's visible to this one sensor.
[03:48.340 --> 03:51.200]  Like, you know, you've got your firewall sat at the, say you've got it sat
[03:51.200 --> 03:52.260]  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:00.060]  You might have an intrusion detection system sat on one segment
[04:00.060 --> 04:01.780]  of the network that sees what's going on there,
[04:01.780 --> 04:04.400]  but it doesn't see what's going on on another segment of the network.
[04:04.400 --> 04:07.480]  And to take all these little pictures, pieces of information,
[04:07.480 --> 04:09.780]  and to put them together to get a more complete view
[04:09.780 --> 04:13.820]  of what someone was doing while they were attacking the network.
[04:13.840 --> 04:18.240]  And did this through using radar tracking algorithms,
[04:18.240 --> 04:21.440]  specifically Bayesian multiple hypothesis tracking.
[04:22.740 --> 04:26.820]  And making an analogy to the world of computer security
[04:26.820 --> 04:31.080]  where our firewalls, our IDS, our humans looking at what's going
[04:31.080 --> 04:34.580]  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:39.300]  The actions that the person out there trying to break
[04:39.300 --> 04:41.820]  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:53.840]  We've got inaccurate data, potentially, about what's going on,
[04:53.840 --> 04:56.100]  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:08.300]  The idea, how this works, this idea of this multiple hypothesis tracking is
[05:08.920 --> 05:12.760]  as events occur on the network, as an event is
[05:12.760 --> 05:16.080]  when a sensor recognizes that something's occurring.
[05:16.080 --> 05:20.160]  When something actually pops up on the sensor, when it gives a report,
[05:20.160 --> 05:23.080]  when you've got an IDS that tells you, hey, I think I see something,
[05:23.080 --> 05:26.440]  when you've got a firewall that decides it's not going to allow this packet
[05:26.440 --> 05:29.300]  or it sees something unusual, when you've got your sysadmin
[05:29.300 --> 05:32.880]  on your network saying, 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:38.260]  And say, for example, we're sat there and one
[05:38.260 --> 05:41.500]  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:50.140]  In this case, if we've got a single scan coming in from the outside world,
[05:50.160 --> 05:52.960]  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:02.100]  Really, I guess, actually, technically, you can make two hypotheses
[06:02.100 --> 06:03.060]  at this point.
[06:03.060 --> 06:07.580]  You can say, hey, there's a port scan going on, or alternatively,
[06:07.580 --> 06:11.200]  my IDS isn't working properly, and this is a false positive.
[06:12.560 --> 06:16.420]  Then, as other events occur, say you see a buffer overflow attack
[06:16.420 --> 06:18.500]  against a machine following that.
[06:18.500 --> 06:21.080]  Well, what could be going on now?
[06:21.080 --> 06:24.880]  We could make the assumption that the port scan is being followed
[06:24.880 --> 06:26.280]  up by a buffer overflow.
[06:26.280 --> 06:28.900]  Someone scanned a machine for a vulnerability, then they attacked
[06:28.900 --> 06:30.960]  that particular vulnerability on it.
[06:30.960 --> 06:35.700]  Or, potentially, these could be two unrelated events,
[06:35.700 --> 06:38.500]  that the port scan could be part of one attack,
[06:38.500 --> 06:43.000]  the buffer overflow could be part of a different attack on the system.
[06:44.640 --> 06:47.720]  And what we were trying to do with this system was trying
[06:47.720 --> 06:49.940]  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 --> 06:59.040]  In this particular case, if the port scan is a scan against, I don't know,
[06:59.040 --> 07:04.140]  against port 80, and the buffer overflow is a buffer overflow
[07:04.140 --> 07:09.200]  against an IIS server, chances are those two things are related.
[07:09.200 --> 07:12.660]  If the port scan doesn't match up with what the buffer overflow was,
[07:12.660 --> 07:14.240]  chances are they're not related.
[07:14.240 --> 07:18.980]  But, you can extrapolate from this idea into much more complicated systems
[07:18.980 --> 07:23.420]  and much more complicated series of events, of trying to piece together the pieces
[07:23.420 --> 07:28.000]  and figure out whether or not all of these events and all of these things
[07:28.000 --> 07:31.660]  that we see occurring across the network are related together,
[07:31.660 --> 07:34.880]  are they not related together, are they likely to be something real,
[07:34.880 --> 07:40.220]  are they likely to be a false positive caused by a imperfect sensor,
[07:40.220 --> 07:43.800]  imperfect IDS, or firewall, or human in the loop.
[07:45.720 --> 07:49.500]  Actually, when I was working on this, one of the most interesting sources of data
[07:49.500 --> 07:53.920]  that I had to work with came from the Capture the Flag games here at DEF CON.
[07:53.920 --> 07:57.340]  Luckily, the SHMOO group captures all of that data that goes
[07:57.340 --> 07:58.740]  on during the Capture the Flag game.
[07:58.740 --> 08:00.540]  They capture all of that network traffic.
[08:00.820 --> 08:05.800]  And that provided a great playground to work in, to try and see if
[08:05.800 --> 08:08.200]  that information could be correlated together.
[08:08.240 --> 08:10.620]  And this little graph I got up here, I mean, this is kind
[08:10.620 --> 08:12.040]  of just pulled right out of context.
[08:12.040 --> 08:15.840]  These are some slides I grabbed just to give a bit of background
[08:15.840 --> 08:19.240]  about the previous research in this.
[08:20.400 --> 08:26.460]  Basically, what this was showing is, as you let the number of hypotheses
[08:27.100 --> 08:34.180]  that you consider increase, in that previous example, I said that we had
[08:34.180 --> 08:37.540]  the two hypotheses, either these two events are unrelated,
[08:37.540 --> 08:42.020]  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:49.240]  And then we look at the evidence that's going on, and we evaluate them,
[08:49.240 --> 08:54.220]  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:00.700]  We'll have a certain confidence level, and how confident do we believe
[09:00.700 --> 09:02.060]  in this hypothesis?
[09:02.760 --> 09:06.540]  As more information comes in, we'll build more hypotheses,
[09:06.540 --> 09:11.760]  and we re-evaluate the likelihood of our existing hypotheses.
[09:11.760 --> 09:18.300]  Eventually, at least in theory, this will eventually converge to a point
[09:18.300 --> 09:23.020]  where one hypothesis is clearly the winning hypothesis.
[09:23.120 --> 09:26.880]  Now, the problem with it, I said that's in theory, the problem with that is,
[09:26.880 --> 09:31.880]  you have to consider every possible hypothesis in order to do that,
[09:31.880 --> 09:34.940]  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:40.700]  There's a lot of work on the pruning of them, deciding which ones you want
[09:40.700 --> 09:42.580]  to keep, which ones you want to throw away.
[09:42.700 --> 09:46.780]  And what this graph is just showing here was, along the bottom is a number
[09:46.780 --> 09:51.320]  of hypotheses that were allowed to remain in the system, going from, well,
[09:51.320 --> 09:54.920]  at the bottom one, all the way up to 1,000, and the accuracy
[09:54.920 --> 09:58.820]  of how well it correlated the different attacks together.
[09:58.820 --> 10:04.400]  And it never quite got up to 100%, but it got up into about 93,
[10:04.400 --> 10:10.680]  94% accuracy on the capture-the-flag data, being able to piece together what we're seeing
[10:10.700 --> 10:12.040]  and what were related attacks.
[10:12.040 --> 10:15.860]  And now, of course, this was actually correlated against the baseline,
[10:15.860 --> 10:21.600]  was done by hand, taking, we, I, and a few others that helped me,
[10:21.600 --> 10:27.020]  took the data over the capture-the-flag game over about a,
[10:27.020 --> 10:29.820]  I think it was about an eight-hour period, and by hand,
[10:29.820 --> 10:33.080]  figured out what was related information, what were related attacks,
[10:33.080 --> 10:37.460]  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:51.880]  If you've got everything on a same network or related network,
[10:51.880 --> 10:55.620]  where you're likely to see lots of related events, it works well.
[10:55.660 --> 10:58.580]  If you've got this distributed over large networks, where you're likely
[10:58.580 --> 11:03.200]  to see many more unrelated events than related events,
[11:03.200 --> 11:06.460]  it goes, the accuracy goes down a bit, or at least the amount of work you have
[11:06.460 --> 11:10.040]  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:21.580]  And this got me thinking about, so, this was a system that had developed
[11:21.580 --> 11:25.800]  to try and detect related information on a network.
[11:25.840 --> 11:27.840]  And then, of course, you know, once you can do that,
[11:27.840 --> 11:29.120]  you always think about the next step.
[11:29.120 --> 11:32.540]  And once the next step, once you can detect something, you figure out how
[11:32.540 --> 11:34.680]  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:47.420]  How could you avoid detection on a network that was well-observed,
[11:47.420 --> 11:51.480]  well-monitored, and where the information was well-correlated,
[11:51.480 --> 11:57.420]  where you couldn't rely on the guy sat over on this part of the network not knowing what the guy sat
[11:57.420 --> 12:00.400]  over on this other part of the network was doing, or seeing,
[12:00.400 --> 12:02.060]  or knew about what was going on.
[12:02.060 --> 12:04.940]  If you assume that there was complete coverage of the network,
[12:04.940 --> 12:08.060]  how could you hide what was going on on there?
[12:08.060 --> 12:12.020]  And I'm not necessarily, I'm not talking about so much the detection
[12:12.020 --> 12:17.960]  of a specific attack, like someone does a buffer overflow against a web server,
[12:17.960 --> 12:23.120]  they do, you know, whatever other type of initial attack to gain access to the system.
[12:23.120 --> 12:27.020]  But assuming they're already on there, they've got on to the system and they want
[12:27.020 --> 12:29.360]  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:48.800]  So, you have to look at this from the point of view
[12:48.800 --> 12:51.460]  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 --> 12:59.200]  If you've got a, you know, I guess, I mean, I guess, unless you get lucky
[12:59.200 --> 13:02.000]  and you see a system out there that's got a ton of vulnerabilities on it,
[13:02.000 --> 13:03.400]  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:18.520]  So, any tool that's written to, to initially gain access
[13:18.520 --> 13:21.680]  to a system usually has a fairly limited life span.
[13:21.680 --> 13:26.440]  At least it's limited, limited life span in the realm of people
[13:26.440 --> 13:27.980]  who actually care about security.
[13:27.980 --> 13:31.500]  You always find some bozo out there who never updates anything,
[13:31.500 --> 13:33.220]  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:44.120]  However, once you have access to a machine and all you're worried
[13:44.120 --> 13:48.560]  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:54.720]  We're not stuck with any traditional communication protocol that's
[13:54.720 --> 13:56.080]  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:36.080]  In general, I pick the IDS and I say software human because, you know,
[14:36.080 --> 14:39.640]  whatever's looking at your network, whether it's automated or whether it's a person,
[14:39.640 --> 14:42.440]  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:50.480]  And this, this applies, um, I think the IDS system in at least one sense is the most
[14:50.480 --> 14:55.100]  general case and you can kind of, uh, find derivative cases that cover this,
[14:55.100 --> 14:58.500]  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:09.620]  You know, if you, if you know exactly what you're looking for, you know,
[15:09.620 --> 15:13.460]  you see this packet go by, it's something bad, you want to throw up an alert about it.
[15:13.460 --> 15:17.100]  Hey, that's great, you can catch it every time, it'll never get by,
[15:17.100 --> 15:19.000]  you know, you've got that one nailed.
[15:19.500 --> 15:24.060]  The only way to avoid that type of detection is to use either an unknown method
[15:24.060 --> 15:29.020]  or something perhaps that changes constantly, never use the same method twice.
[15:30.580 --> 15:34.300]  The anomaly detection, it doesn't detect misuse of the system,
[15:34.300 --> 15:37.800]  it doesn't detect something malicious, it just detects something unusual.
[15:37.800 --> 15:44.580]  So, it's, it's not necessarily really great at trying to pick
[15:44.580 --> 15:46.660]  up something bad happening on your network,
[15:46.660 --> 15:48.580]  but it'll pick up something unusual.
[15:48.820 --> 15:51.960]  And it's really, if the signature detection doesn't work,
[15:51.960 --> 15:55.040]  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:06.780]  If you've got a way of communicating or a way of doing anything on the network
[16:06.780 --> 16:10.160]  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:23.620]  So, the only alternative is to use something that you can't write a signature for,
[16:23.620 --> 16:28.720]  something that changes constantly, something that is quote unquote random,
[16:28.720 --> 16:32.600]  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:41.620]  Not only do we have to do something, it's kind of a catch-22 in a way,
[16:41.620 --> 16:44.640]  because we've got to do something that's very unusual, you know,
[16:44.640 --> 16:47.640]  this kind of random changing communication protocol,
[16:47.640 --> 16:49.880]  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:11.680]  You can sit back and discover what type of traffic is allowed
[17:11.680 --> 17:14.860]  on the network, what does normal traffic look like,
[17:14.860 --> 17:19.880]  and kind of build yourself a map of both what is going on on the network,
[17:19.880 --> 17:21.580]  what the structure of the network is,
[17:21.580 --> 17:24.660]  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:42.780]  But the key thing is, is that this is what, generally,
[17:42.780 --> 17:46.140]  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:04.960]  You know, the firewall's gonna drop any connection,
[18:04.960 --> 18:06.720]  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:13.280]  That, at certain intervals, perhaps at random intervals,
[18:13.280 --> 18:15.480]  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:21.260]  Except that, what that web request is doing is coming to your computer
[18:21.260 --> 18:25.960]  on the outside, getting the next command that you've told, told it to do.
[18:25.960 --> 18:31.680]  It carries it back as the HTTP response to the, to the target computer,
[18:31.680 --> 18:33.900]  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:46.620]  Once someone knows to look for it, if you stick with it too long,
[18:46.620 --> 18:49.540]  they're gonna look for it, they're gonna see it, it's gonna stand out.
[18:50.380 --> 18:54.760]  Similarly, carrying data commands and ICMP echo, echo response packets,
[18:54.760 --> 18:56.820]  same sort of, same sort of idea.
[18:57.160 --> 19:03.900]  What I'm trying to do with this project is to automate this process and make it run on the fly
[19:03.900 --> 19:10.140]  and may, and have it adapt itself to whatever network it's currently working on.
[19:10.140 --> 19:14.100]  Look at what's going on on the network, decide what to do on the network,
[19:14.100 --> 19:17.300]  decide what will work there, and then carry it out.
[19:19.220 --> 19:25.180]  So, some aspects of network traffic are gonna have a low entropy,
[19:25.180 --> 19:26.580]  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:53.660]  Maybe outgoing web requests, you know, people, different people surfing the web,
[19:53.660 --> 19:56.540]  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:08.940]  The, the more entropy you have on the system,
[20:08.940 --> 20:12.720]  the more information you can hide in that.
[20:12.720 --> 20:19.280]  This is like if you look at, if you look at steganography, for example,
[20:19.280 --> 20:22.080]  you know, you're trying to hide information in something else.
[20:22.080 --> 20:25.020]  If you've got a bitmap, a bitmap has lots and lots
[20:25.020 --> 20:28.940]  of redundant information in it, versus a JPEG image.
[20:28.940 --> 20:30.440]  A JPEG has taken a lot of that redundant information,
[20:31.180 --> 20:33.700]  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:45.040]  So, if we find what has the highest entropy on that network,
[20:45.040 --> 20:48.800]  what communication channels have the highest degree of randomness,
[20:48.800 --> 20:51.040]  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 --> 20:58.060]  We can work with the timing of the packets, we can work with packets,
[20:58.060 --> 21:00.440]  sending out packets that have bad checksums, malicious checksums,
[21:00.460 --> 21:03.860]  malformed checksums, all sorts of different things that we can play with.
[21:03.860 --> 21:08.220]  We don't have to use a SSH or a Telnet or some other standard type
[21:08.220 --> 21:10.180]  of communication format.
[21:10.180 --> 21:14.660]  We can send crafted packets where the information is carried in all sorts
[21:14.660 --> 21:18.040]  of the different little pieces of information inside that packet.
[21:18.040 --> 21:21.420]  The key is, we just have to make sure it doesn't look unusual
[21:21.420 --> 21:23.360]  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:53.740]  We're going to look at what happens on the network, figure out what's allowed,
[21:53.740 --> 21:58.400]  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:33.160]  On the network, if we just sit there and listen,
[22:33.160 --> 22:35.320]  what can we learn by listening on the network?
[22:35.320 --> 22:38.420]  There's all sorts of things that we can find
[22:38.420 --> 22:41.880]  out by just sitting there and listening, not doing anything active,
[22:41.880 --> 22:43.780]  not doing anything to be discovered.
[22:43.780 --> 22:46.620]  You can figure out what types of packets are allowed inside the network,
[22:46.620 --> 22:48.820]  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:10.240]  And from this, get an idea of what is allowed to move around this network,
[23:10.240 --> 23:15.280]  what is moving around this network, and what we can inject into the data flowing
[23:15.280 --> 23:19.400]  around without being, without sticking out like a sore thumb
[23:19.400 --> 23:21.640]  and being immediately identified.
[23:22.800 --> 23:26.480]  So if we narrow down these choices, we start with the ability to send any type of packet,
[23:26.480 --> 23:28.360]  you know, send it to any port whatsoever.
[23:28.640 --> 23:31.360]  We start paring it down based on what's available,
[23:31.360 --> 23:37.600]  figure out what has the highest entropy, look at this, look at the type of packets based
[23:37.600 --> 23:40.900]  on the protocol, the ports they're using, et cetera,
[23:40.900 --> 23:45.180]  and look at the entropy based on how often do these packets fly,
[23:45.180 --> 23:48.440]  how different is the data in these packets whenever they go by,
[23:48.440 --> 23:51.160]  what different machines do these types of packets go to,
[23:51.160 --> 23:55.660]  and then pick a channel that we know we can get from point A to point B.
[23:55.660 --> 23:58.620]  We can get from inside the network, we've got access to the machine network,
[23:58.640 --> 24:03.120]  out of that network over to the place where we want to get the information to,
[24:03.120 --> 24:05.500]  or back and forth, vice versa, either way.
[24:05.500 --> 24:08.940]  We can figure out what can get into one, out of one network,
[24:08.940 --> 24:11.080]  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:18.120]  The packets that you send out, the packets that you send going out one way,
[24:18.120 --> 24:21.140]  don't have to look a heck of a lot like the packets coming back in the other way.
[24:21.160 --> 24:24.580]  As long as they're getting to the right segment on the network,
[24:24.580 --> 24:27.280]  as long as they're getting down to the right branch off of your switch
[24:27.280 --> 24:33.600]  so that it can be picked up by a, by a network card in promiscuous mode,
[24:33.600 --> 24:37.700]  as long as you can get down that far and you know what to look for,
[24:37.700 --> 24:40.460]  each guy on each end knows what to look for, you don't have
[24:40.460 --> 24:42.980]  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 --> 24:58.340]  If you've got a piece of software running on the inside of this network
[24:58.340 --> 25:00.860]  and it's gonna start communicating with you on the outside
[25:00.860 --> 25:05.740]  and you don't know what particular communication scheme it's gonna be using,
[25:05.740 --> 25:09.220]  there's some difficulties in getting, in getting that first packet out of there,
[25:09.220 --> 25:13.460]  that first piece of information to the outside without having it be something
[25:13.460 --> 25:15.780]  that can easily be written as a signature.
[25:15.780 --> 25:20.880]  Because it's hard to, it's hard to change things or inject randomness
[25:21.240 --> 25:23.760]  into the first bit of communication.
[25:23.760 --> 25:30.920]  There's some, there's some ways that we can limit how signature vulnerable
[25:30.920 --> 25:34.360]  that first bit of communication is, but that's one of, that is,
[25:34.360 --> 25:37.020]  that's one of the points that needs,
[25:37.020 --> 25:39.700]  that presents some challenge and needs some work on in this.
[25:40.420 --> 25:43.220]  Having the communication software itself remain undetected
[25:43.220 --> 25:45.620]  on the remote machine, not talking about what the software is doing,
[25:45.620 --> 25:48.520]  but actually having the software itself avoid detection,
[25:48.520 --> 25:49.620]  of course that's another challenge,
[25:49.620 --> 25:52.020]  but that's a completely different story.
[25:52.900 --> 25:57.700]  That's, whether it's something that's using a polymorphic code,
[25:57.700 --> 26:01.100]  that is, that changes from one installation to another,
[26:01.100 --> 26:03.400]  or even changes itself constantly.
[26:03.400 --> 26:05.400]  There are ways around that, but it is a different,
[26:05.400 --> 26:07.960]  but it is another challenge in there.
[26:08.300 --> 26:11.400]  The third one, that's actually I think a fairly interesting one,
[26:11.400 --> 26:13.780]  is the problem on a low entropy network.
[26:13.820 --> 26:15.400]  What do you do when there's not a whole lot
[26:15.400 --> 26:17.540]  of randomness going on on the network?
[26:18.000 --> 26:20.400]  You know, if there's not a lot of randomness in the packets,
[26:20.400 --> 26:22.000]  how do we stay hidden in it?
[26:22.020 --> 26:23.760]  We have to ensure that every packet
[26:23.760 --> 26:29.520]  that we send out doesn't significantly affect the statistical baseline
[26:29.520 --> 26:32.680]  of the network, so that an anomaly detection system sat
[26:32.680 --> 26:38.500]  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:44.260]  It won't push the statistical analysis of the network beyond the limits,
[26:44.260 --> 26:46.180]  beyond the thresholds that we currently have,
[26:46.180 --> 26:48.080]  and it will avoid becoming an anomaly.
[26:48.080 --> 26:52.000]  This is actually the area right now that I'm doing,
[26:52.000 --> 26:58.720]  concentrating on, trying to figure out the best methods for communicating
[26:58.720 --> 27:02.940]  and picking channels, and picking well-hidden channels
[27:02.940 --> 27:05.420]  on a low entropy network.
[27:05.540 --> 27:11.200]  So, just as a summary in the system, you know, what's real, what's not real,
[27:11.200 --> 27:16.840]  so far the allowed protocols discovery, the network architecture discovery,
[27:16.840 --> 27:21.220]  the statistical profiling of the network, those are,
[27:21.220 --> 27:25.880]  those are working prototypes.
[27:25.880 --> 27:28.920]  Those modules, those parts of the system are working prototypes.
[27:28.920 --> 27:31.100]  Next stages that we're moving towards are the selection
[27:31.100 --> 27:34.500]  of the communication scheme, implementation of the communication,
[27:34.500 --> 27:39.740]  and the adaptation to changing network conditions.
[27:39.920 --> 27:45.420]  I hope that by this time next year this will actually be a working package
[27:45.840 --> 27:48.480]  that I can give maybe a bit better presentation and demonstration
[27:48.980 --> 27:50.180]  of what it's actually doing.
[27:50.180 --> 27:51.200]  But this is the current idea.
[27:51.980 --> 27:56.220]  Anybody that has any interest in this, or any ideas, or feedback,
[27:56.220 --> 27:59.540]  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:32.250]  He asked, is there any concept of trying
[28:32.250 --> 28:36.030]  to actually change the baseline of the network so that you can do something
[28:36.030 --> 28:39.850]  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:49.670]  But actually changing, injecting stuff in slow enough that the system,
[28:49.670 --> 28:52.750]  the anomaly detection system adapts to it and thinks that's normal,
[28:52.750 --> 28:56.730]  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:38.160]  So, that's fair enough.
[29:38.400 --> 29:40.160]  Thank you.
[29:42.370 --> 29:43.330]  Sorry.