 Good morning, I am Ryan Lin and this is pig finding truffles without leaving a trace. We are going to start off today with a brief introduction and then talk about why we're here for those of us that are awake in here. And then after that we're going to figure out how this can help each of us. And I absolutely hate slides so most of this is going to be demos. We're going to talk a little bit about how the different stuff works and then we're going to go over the different protocols and plugins that the protocol for pig supports and we're going to talk about remediation. So first of all I am Ryan Lin, I'm a senior security consultant at Trustwave. I also like to play with cool toys so I've contributed to Metasploit and Beef and other stuff. And that's my website and Twitter ID if you're interested in things I say. So where are we here? While I was looking at network traffic doing pentesting, I was getting frustrated because looking at wire shark data is really cool but it's kind of a pain because getting data out of that to prioritize and really get into some sort of manageable format isn't necessarily easy. It's mostly a lot of down arrow and going oh that's interesting which isn't really interesting at all. So I wanted an easy way to identify hosts and resources on a network. And primarily what I'm talking about is local segments. So for internal pentests frequently we hit a point where we're dropped on a local network segment and we want to know what's there. We can port scan it all and light up host IDS and all that sort of stuff but it's usually a good idea to start off by listening for a little bit and seeing what we see. So I wanted an easy way to collect that data. I wanted to be able to identify hosts and resources that are on a network and also profile individuals. It's amazing how much information some people attach to their computer whether it be their name, which I sort of accidentally did that and I realized it while I was working on the tool. So you'll see a packet of me being stupid in a couple minutes. Also to be able to determine network architecture. So looking at what devices are on a network. In some cases how they're configured and other goodness. Also a lot of the time it will give us machine and user naming schemes. So if you're needing to brute force a user someplace if they go ahead and give you the user ID without asking for it that's kind of helpful. But the big thing I wanted to do was be completely silent. A lot of passive information gathering tools out there require you to essentially man in the middle of the network. Well that's good and man in the middle and a lot of situations is very nice. But I kind of think that that's the thing that you should do after you start listening. So I wanted something that would allow me to do this with no IP address so I could look at the broadcast and multicast traffic on the network without actually participating in being able to, for instance, sending out a DHCP request. I wanted to just be able to listen on the network. And the man in the middle piece for me was important because again I wanted to make sure that this was the first step and once I had an idea of what I was looking at this will help me figure out which host I might be targeting for specific man in the middle activities where I would look at more traffic. So where are we here? First of all for passive information gathering it's good to understand what's on your network. What's talking, what protocols you may have broadcasting that you don't intend to be broadcasting. A lot of these are easily configurable through domain policies and so we're going to look at understanding what sort of packets are broadcast automatically. Also the packet parsing kind of sounds like fun. But I wanted to make this information easier for everyone to access. So like I said, Wireshark is interesting sort of. But having a way to automatically pull out data out of PCAP or off the network and put it into something that is easy to manage is important. And so for this example, since we have already more and more information gathering in Metasploit, I chose Metasploit to use as the back end. So what we're going to be looking at is how to pull information from the network through passive listening and then insert that into Metasploit so that we can access it later. But also we're going to look at how we can easily leverage that data afterwards for pentests or for sort of easier reporting. And you guys could just be here because you're waiting for the next talk. But hopefully you're here for me. So how will this help you? So for assist admin, it's good to know what information you're sending out. Want to make sure that you're not giving away more information about your server or your resources than you want to. If you're a network admin or a client side admin, this is even more important because knowing this stuff helps you build good hardening guidelines for your clients so that when someone wanders into a Starbucks, you're not giving away a great deal of information about how your company's assets are configured. So for a pentester, obviously we want to know as much as possible about what's going on in the segment that we're on so that we can figure out which hosts are going to be prime targets for attack. So for that aspect, this project really is helpful for us. And so for everyone, not everybody wants to look through wire shark packets. So this is mainly for people who are tech savvy and are interested in seeing what types of information their machine is sending out. If you want to know whether or not every time you connect to a wireless, if everybody knows that your name is Jim Bob and you have an iPhone. So that really helps with that process. Also, the Metasploit database really does make it easier to manage data. So this project is a step to hopefully encourage more people to be able to interface with that to pull some of this information. Also, I want a way to organize and manage the results with Dratis. So Dratis is a decent reporting framework. It has the ability to treat each entity as a node. And so one of the things I did is I wrote a Dratis plug-in that will allow us to pull all the Metasploit data that we have into Dratis so that we can look at it in an easier fashion. This will also allow us to take the information that we've gathered and add additional notes to it and correlate it with other information we've gathered. And also, this is a good way to stay quiet on the network. If you're worrying about tipping off things that are watching, whether it be in IPS or HIPs or any of that stuff, just listening isn't going to start triggering alerts. So before you start getting yourself blocked from things, this is a good first step. So talking is kind of boring, so show me. So the first thing we're going to do is on basic gathering data. I was lucky enough to get some of the Wall of Sheep data from Ryan at the Wall of Sheep desk. And so we're going to look at a little bit of that right now. So first thing we're going to do is load up MSF console, which for those who are not familiar with Metasploit, MSF console is the command line interface into the Metasploit framework. And the Metasploit framework lets us do a number of things, including facilities exploit dev but also for pentesters gives us an easy place to have both a framework for running exploits as well as different types of auxiliary modules that will allow us to do everything from like this, the passive information gathering to basic port scanning. So Metasploit framework is very powerful. What I'm going to do next is connect to a local database. So we're going to do DB connect, actually DB create. And the DB create will connect to the local Postgres database that I have and go ahead and create the table structure that we're going to use. The next thing I'm going to do is use the module that I created for the passive information gathering, which this is going to be released tomorrow morning because I fixed a bunch of stuff last night. As I got the DEF CON network traffic, it turns out that not everybody since properly formed network traffic at DEF CON, who would have thought? So I sort of found some bugs in the process of getting the wall of sheep data. So this should be out tomorrow. This information is stored in the auxiliary tree under sniffers and it's called pig. So from here, we can look at the options. The two primary things we need to do is set a pcap file. And in this case, we're going to look at two different protocols, CDP and SSDP, which is network plug and play. The other thing that we're going to do is, so I'm not sure why it's here, but the Sniffer framework for Metasploit requires an R host, which is typically designed for the host that you're going to attack. There's also a filter, which would be if you only want to listen to specific things. But for right now, until we get it fixed, you still have to set an R host to something. So it's completely ignored. So just set it to whatever you want. So right now, when we look at the hosts that are in the database, there's nothing there. And notes as well. So when we run the plug in, we can see that it's pulling in host information for a couple of different things. We see one SSDP host, which is again the network plug and play. And there's CDP devices detected, but they don't have IP addresses. So we're seeing broadcast traffic from hosts that are actually multi-gass traffic from hosts that aren't actually on the network. So when we go back to DB hosts, we see a new host was added, the one through network plug and play. And when we look at the DB notes, we can see a couple of different things. We can see under type passive CDP, and under the next line is a passive SSDP. To be able to query the stuff directly, you can just do a dash T and type in the type of information you want. And so from this, we can see that we have a CDP packet. And obviously, from just listening to the network, we've gained quite a bit of information. We know that it's a switch. We know what port is connected. We know what capabilities it has. We know the full banner, including version and type of switch. And we even know the native VLAN. So we've already, just by listening for a second, gotten quite a bit of information about probably what type of infrastructure is being run and what type of hardware is out there. So let's look at one other. So this is the broadcast traffic. So you can see here there is a number of DHCP requests going out and a couple of other things. So the DHCP packets have some very interesting information in them. In addition to having the MAC address, typically they also have information in them that may indicate what type of operating system it is, especially when you start looking at what information is requested. So that makes these very valuable. The bad thing is, is you don't always have an IP address to go with the MAC address. So one of the things that I've changed about this is if we don't have a MAC address, we will create an arbitrary IP address based off of the last four octets of the MAC address that will allow us to go ahead and capture that data. For the Metasploit framework, one of the things I had to work around was that every asset for a note has to be associated with an IP address. So I just randomly created IP addresses. So if we look at our hosts, obviously there's a lot of random IP addresses there. But it allows us to, when we look at the DHCP network, we actually be able to capture each individual piece of information. So these, for instance, on the DEF CON network seem to be a lot of people changing MAC addresses and just sending out requests to see what comes back. So there's not a lot of information here, but I'm going to show some stuff that is more interesting in a moment. So that is the basics of actually gathering the data. So we've already looked at a little bit how to view the collected data with Metasploit. So let's look and see what information we see through Dredis real quick. So for those of you that aren't familiar, Dredis is a reporting framework that is written in Rails. So what we're going to do here is use the thor command, which is a gem that you install as part of, as part of Dredis, to do a list, to list all of the different things that we can run. So when we do the list, we can see that we can use thor to back things up to reset portions or the server, which is what actually runs Dredis itself. So right now Dredis is starting up and we see that it is started up on localhost. We can see the port number is 3,004. So we will start up web browser and we will log in to Dredis. So Dredis has a couple of different areas. One is over here where we will have all the nodes and then all of the information about the different things that we are reporting on will show up over here. So now that Dredis is loaded, we have an import task which will allow us to import all of the data into it. So I'm going to back around this. And if we do a thor list again and grab MSF, we can see that there is a command to import all of the MSF configuration information. To do that, it uses XMLRPC. So we are going to come over to our metasploit instance and we are going to load the XMLRPC plugin. We are going to specify a password of test. And so when that runs, we can see that it is loaded on localhost on 55553 and has username of MSF and a password of test. So when we come back over here, we can find our thor command again. And so we do thor, Dredis, import MSF, all. And so what we should see here is beginning import of the nodes and then the filter runs successfully. So when we come back to the Dredis framework, we can refresh in the tree. We now have a metasploit branch and all of the IP addresses that we had show up before. So before, you know, it was kind of hard to get an image of what all of that information was, but this is a little bit easier to navigate. So for the passive DHCP data, for instance, we can just through double clicking see all of the different information that we were able to gather. We can also expand all of these and look at all of the different types of information we have. So in addition to gathering just the nodes, we also have some information about what services are running through the queries that were, or the, through the packets that we were processed. So DB services will show that it picked up two different types of protocols. So we're also getting some basic port scanning out of this as well. So when we go back in Dredis, we can see that the nodes themselves, this SMB browse note is associated with port 138 UDP. So when we look at that, we get some interesting information. We get that we got this through an SMB browser. It's domain is work group. We know the OS version, and we also know what capabilities it has. So it's a workstation. It's not a server. Some interesting stuff comes up here. So a lot of the times when we're doing pent us, people running their own version of SQL server is frequently a way in a lot of the time when people have SQL server on their work stations that's not properly patched or has a bad password. So Windows is really nice. And if you have a SQL server, it broadcasts and tells everyone because everybody should use it because it's awesome. So this shows up here. So if you're looking for SQL servers, I'm going to look at how to programmatically pull some of this stuff in a minute and we can easily go through the notes to look for things like SQL servers. So, and then for the passive SSDP, we're going to look for that in a minute. Again, SSDP I think is simple service discovery protocol, which is the awesome network plug-in play. So this device that is doing network plug-in play, we know some cool stuff about it. We know it's Windows NT 5.1, and it's universal plug-in play. And if we want to find out more about it, the packet that gets sent out has an awesome URL we can go to you to find out everything we want to about how to connect to this host via plug-in play. So while this itself doesn't give you an easy way to get all the information because you have to send out a separate request to get it, basically we can script this, pull out the URLs, and then run curl or whatever else we want to just iterate through all the plug-in play devices to get their configuration information. So this is a nice step forward with that. The next thing I am going to do is to show you a little bit more different types of data. So we've seen two pieces so far. And I wanted to keep it small for the purposes of looking at Dratus because Dratus, as you start getting larger and larger, by default it uses SQLite 3. The more data you shove into the SQLite 3 database, the slower it gets. So if you're going to be doing Dratus with a large number of hosts, go ahead and edit the files to switch it to Postgres, otherwise you will be very, very sad. So we're going to set our pcat file this time. Thank you. And so here when we run this one, we see a couple of different other things if you can read that fast. So here we're seeing information from Dropbox. We're seeing MDNS packets, which MDNS is awesome. MDNS is multicast DNS which allows you to do some DNS-y things on your local network. One of the things that I hope to do for the next version is to eliminate a lot of this redundancy. For the packet parsing, I wanted to do it as quickly as possible. But the downside is, is when you start searching for notes before you post them into the framework, everything starts slowing down a lot. So right now basically every note it sees goes in, which is kind of good and kind of bad, but it's good to see what some of this information is. So if we look at our DB hosts again, we have quite a few more hosts and quite a few more notes. So looking at some of the interesting things, I also have to make this a little bit more consistent, apparently. So for MDNS, we can also see that for instance all of the information about the photo smart printer that was attached to the network. And so we have quite a bit of information about it just by the nature of it being on the network. So one of the other things I wanted to talk about was the phone plug. So for those of you who have not seen one before, this is a phone plug. It's relatively small, has USB port if you want to connect it to wireless, has ethernet if you want to connect it to ethernet. But it's basically the size of just any power brick. So if you put something interesting on it like CO2 detector or have something else coming out of it so that it looks like it's just a normal power cord, somebody may not even notice that it's there. So there's a lot of development being done for these guys so that you can use tools like the passive information gathering. There was another talk I think yesterday on doing transparent bridging with one of these guys so that you can bypass some of the NAC restrictions. But these are becoming more and more popular as pen test tools because you can easily get them in somewhere and they probably won't go noticed very, very often, especially if you doctor them up a little bit. I mean if you have like a great big antenna hanging off of it and, you know, write pen test device on it, people will go, huh, I wonder if that's supposed to be here? But it's easy to doctor up so that it looks like it's supposed to be somewhere. So something along the lines of the Pony Express is a good way to get some of these tools onto a network. So I was trying to get a demo together for this, but I don't have one yet. But basically this is running a cut down version of Backtrack. So you have a lot of the same tools that you would have with Backtrack, including if you have wireless being able to join wireless networks and sniff traffic. There's even a 3G version that you can combine with typical wireless. So if you don't have an easy egress method out of the network, you can go ahead and have it call back to you through SSH over 3G. And so at that point you can bridge your, you can get on to the network or be able to at least listen to network traffic without directly being there. So the 3G is interesting because it bypasses, you know, obviously you don't have to worry about what someone's egress filtering is like if it's going over 3G. So now that we've seen the stuff, we're going to talk a little bit more about code and how all of the stuff fits together. So if you're not interested in that stuff, most of the demos are done. We're going to look a little bit more about how to build some of these things. So if you're interested in the programming part, we're going to talk about some of that too. But this is basically a Metasploit framework plug-in. It does an auxiliary module that does, that accesses the Sniffer library that allows us to pull all this information in. The module that we're using for most of the parsing is Racket. Unfortunately, Racket doesn't have all the protocols that we're doing. So for instance, this has its own MD&S parser and some other things that hopefully will be able to contribute back to Racket in the future once I get the stuff stable enough so that everybody can parse MD&S packets pretty easily. From the core Sniffer portion, there's a number of helper modules. These helper modules let you define the protocol parsing for each individual protocol that you want to look at into a separate file. In addition, you set rules for when those files should be triggered. So you're not running every filter against every single packet you see. So a lot of the things for like the multicast traffic, we're listening to specific multicast broadcast addresses so that we don't have to send things to every filter. So we're going to look at one of these real quick. So the individual plugins are kept under the data and then exploits and then I have created a subdirectory called PIG in here. So these are the listing of all of the different protocols that we support. So for instance, for Groove, we have the basically we have to define a new PIG parser. We call it PIG Groove. Every one of these different protocol parsers is prefixed with PIG so that we know exactly what it is as far as classes go. So the register rules tells us what rules it should trigger on. So it should trigger on a destination UDP port of 12.11 and a network broadcast basically. So from there, when it sees something that matches that, it passes to the parse function, which we go ahead and break out the ethernet and IP portions of the packet and assign those. But Racket will let us take the IP portion and get a UDP packet out of it. And then from there basically we can parse all of the different pieces and everything pretty much ends with the report note which reports the different pieces in. So the two important pieces of information are the host and the port as far as the report note goes and the protocol as well. Because basically when you specify those it binds the note to a specific port and to a specific IP. If those don't exist it goes ahead and registers that information. So as far as port scanning goes and knowing what things are listening on, as this runs this will go ahead and populate that information. So as far as pulling some of the stuff out programmatically, one of the things that I also wanted to show was we looked at, we looked at for instance the CDP information. So this is a basic Python script that will allow us to pull data from Metasploit through the XML RPC interface. Again the XML RPC interface is the same thing that Dredis uses to pull in the data. So basically we use the XML RPC lib and then the base Metasploit XML RPC is not typical web XML RPC. It is null terminated XML RPC kind of like what Flash uses. So we had to sort of write a fix for that. So the MSF transport is a transport that basically just null terminate stuff instead of tries to do web requests which makes it a little bit easier. So to set up something to be able to query we basically just create a proxy object, connect it to the same port that we set up and we saw when we did the load XML RPC the local host on 55553 with a transport of MSF transport. So here we set the type of note that we're looking for and basically we start off by doing an off log in. The off log in gets us a token and then for the next 10 minutes we can continue to use that token to query any other data we want. So if we got a result of success we logged in otherwise we looked at notes and so basically for this we're only taking the notes that have the type of information we want and putting it out to the screen. So from here we can see that we can directly pull that. Now we can manipulate this however we want. Basically it spits out the raw data structure so if you depending on how you want to do this you can either convert the data structure into a Python data structure from the Ruby format or in a lot of cases I've just been parsing out where I know fields are and so doing Perl regex matches to pull the specific piece of information that you're looking for. So for instance for the SSDP all you're really looking for is the URL. So when we look at that we can just go ahead and get all of the different URLs and this makes it pretty easy and then take those and then fire off a separate process to pull all of the XML configuration files through that. So as far as what is currently in each filter I wanted to talk for a couple minutes about what types of information we're actually gathering. So CDP we looked at for a second it's got the OS version IP address information VLAN information where all of this really comes into handy is if you're doing a pen test a lot of the times you will get things like what the voice over IP VLAN is and other information that can help lead to further compromise. So for instance since you're going ahead and getting all of the OS versions if there's a vulnerability in a certain version of via us this will certainly help you. It also aids in VLAN hopping because it frequently list all of the VLANs that are available and it will also frequently give out the management VLAN information. So the the host that are the IP address that will accept typically SNMP traffic or an SSH connection is frequently given away in CDP as well. So this can sort of unveil other areas of attack just by listening to to the CDP traffic DHCP inform. So there's a couple more things that I want to do with this. But for right now to pull out the Mac address host name the vendor class and request list where a vendor class and request list come in handy is each different version of windows and many of the different versions of Linux have the vendor class and request list in different orders through using these two things together we can fingerprint the host pretty effectively. So we won't know for instance the difference between windows XP service pack two and three will know the difference between windows XP Vista 2000 and and windows 7 which you know if you have windows 2000 out there that's a lot of the time a tip that that may be a host that you want to look more carefully at or you know if you accidentally find like a a windows me box then that's certainly something you want to look at a little closer or shoot. So through those together there are some slight differences between service pack that some people have have done some research on. So we do have the ability to get a little bit finer grain but you lose a little bit of the guarantee isn't quite as strong you can definitely figure out specific version but going down to the individual service pack is sometimes tough. So draw box is very cool. There's been a number of drop box vulnerabilities that have been released and one of the cool things about drop boxes it goes ahead and spits out its version number so if any versions are vulnerable it goes ahead and custom on the research for you I guess. But it also shares all of the shared namespaces the namespaces with the drop boxes that you have access to. So if you have a network and you have three people who are on a network that share the same drop box and two of them are fully patched in one of them is running SQL server then you know which one you want to go after the one that doesn't maybe have a password on the SQL server and so you can look at who has maybe sensitive information or who you may want to attack through some other type of method and figure out who's sharing data back and forth to figure out where relationships are and so all of this is broadcast freely with drop box. So grove which is I think called like SharePoint collaboration or workspaces or something like that now is a pretty interesting protocol. It goes ahead and gives you lots of information about the person who is sitting in front of the computer including whether or not they're online or offline if the grove session is connected or not. So if somebody is as actively connected and hasn't been logged out then you can tell that they're there. It also give you the ports that grove is listening on. But the most interesting thing that I found is that as part of the land sync protocol that it uses it lists out all of the interfaces IP addresses. So where this really becomes interesting is if you're trying to figure out for instance what host may be running VM or you're looking for credit card data. A lot of the tests that we do are PCI related and you hear things like I've got a VPN so you'll never be able to get to my credit card data. Well if you're running workspaces and I can tell which people are connected to the VPN then that's certainly an avenue of attack. Those are the people that I want to try to target to use their host as a relay through the VPN. So this gives out in my opinion sort of one of the worst pieces because it really tells you which targets are most interesting. But it also gives you the grove version so that if there are grove exploits you know which ones are most interesting. MDNS is my favorite one. So it can give you everything from a list of the open ports so it's basically a free port scan for Mac in a lot of cases and a lot of the ones that I see for this are Mac related as far as listening open ports. So basically just from hanging out and listening to MDNS data you can figure out what ports are running, whether or not sharing is enabled and all sorts of other goodies. And the only thing that I can figure out is that my Mac must be a whore because it wants everybody to know what's open. So of course everybody names their Mac Ryan's Mac which I accidentally did. And so the first thing when you set up your Mac you probably want to go through and change some of that information so that it's not as open. But it's an easy way to get people's names. Also the active state of the machine there's a presence protocol or there's a presence field in a lot of these that shows whether or not someone is actively doing things on the computer. So if someone's actively working on the computer it might not be the time to mess with it. When they go home maybe the time to mess with it. Also for things like printers it gives out some really interesting information. I mean if you want to know which printers have staplers or whatever in case you really like staplers you can use this. SMB is you know it's Microsoft so it's trying to be helpful and stuff. So it will go ahead and just tell you the exact version of Windows and host name. And frequently we'll go ahead and give you the main information as well. So if you're just like I could figure out the domain but I'm just going to hang out. It'll be like hey here's my domain. So this really cuts down on figuring out what the Windows infrastructure looks like. The Windows naming schemes and because it pulls it all in automatically it just makes it really easy. Like I said before the SQL server stuff. SSDP is also very cool. This is where you show people all of their security cameras. So apparently the infrastructure IT security guys and the physical security guys don't work together. Because there seems to be a lot of corporate security cameras that the physical security guys are using that still have plug-in play enabled and so they're just screaming out hey come look at my feed. And a lot of places you also may find that they forgot to do things like add passwords. So if you want to watch the front gate or you know secretary or whatever you can do all of that from here. You'll get information about printers, cameras and frequently network gateways. So if you're trying to figure out more about the network topology this is also a good way to do that. It doesn't give you a whole lot of information straight up. It usually gives you a URL and then from that URL you can pull another XML configuration file and usually that gives you a lot of information. There are even devices that will be so friendly is to give you things like the admin username and the URL to do different other things on the system. So you can see the URL just to view the camera or the URL to do admin functions and URL to change the IP address all of those things. And so SSDP is sort of a gateway to more interesting stuff. So we know how to steal lots of cool stuff now. So how do we fix it? For NetBios one of the ways to do it is disable NetBios over TCP. Most places now have a pretty robust DNS structure. So NetBios isn't overly necessary. So one of the things that is worth testing is if your company is still using NetBios over TCP look at what happens when you start disabling that and whether or not problems occur. If you still have a win server you're probably okay and if you're pretty good with auto registering DNS and those sort of things you're probably okay. For SSDP disabling network plug and play is an excellent plan. For most of the stuff it's not necessary. Most places have, you know, DHCP will usually give you the information you need as far as network devices go and I rarely see a need to use the network plug and play features. CDP is tough because from a network admin standpoint it's really helpful to see what's attached on what port. And unfortunately it's really a pain to turn it on selectively. So kind of my feeling on that is for edge devices you probably don't need it. But for core devices it certainly makes it easy to figure out topology. So if somebody is at your core in a place where they can sniff that traffic then you have probably already screwed up. So enabling at the core usually isn't too problematic but enabling on edge devices certainly gives away a lot of information. So DHCP, Cisco has the concept of a DHCP helper. DHCP help helpers can help limit where the DHCP information goes and that will cut down on your ability to leak information via DHCP. Draw box, disable the Lansing protocol and this doesn't happen. Basically you can still get a lot of that same communication that you need and may generate a little bit more traffic but it certainly won't give away as much information about what you have. And since Microsoft is so helpful I haven't found a way to stop Microsoft from helping me. I've been trying for a number of years and generally they're just that helpful. So if anybody figures out a good way to stop groove from telling everybody about your stuff I'd certainly be interested. And MDNS is disabled when possible but it may not always be an option. Some things that talk MDNS don't really have an off button. But obviously if you don't want everybody connecting to your iTunes you can disable some of those features and get away with a little bit more security. So as far as ways to help one of the things that I'm interested in is seeing more types of data. Obviously the DEF CON traffic helped quite a bit because there are lots of weird things going on here. Also the DHCP health studies stuff. I'm partially the way through it but I'm hoping to get a little bit more effort so that I can get more specific with the different types of boxes as far as network fingerprinting with the DHCP parameters. And then also I'm looking at more traffic to just figure out more protocols in general. There's a lot more stuff out there that's broadcasting that what we listed. But hopefully I can get some more of those out there for the next release. And for the future Metropoder actually has sniffing capability too. And with the new way that they did Metropoder modules, some of this stuff is going to be able to be ported so that you can actually do it through sniffing on a box that you have already rooted. So as you attack a new box, get a new shell, this may be something that you can look at to gather information on new segments as you start progressing in pivoting through a network. And again also more protocols because collect data and profit. And I still haven't quite figured in all the question marks but I'm sure we can figure that out. And then again the better OS identification. So if you want to get the code itself, there is where the code is. As far as working with Metasploit goes, there's both the Metasploit website which links to Metasploit and Leash class, which is excellent if you are interested in learning Metasploit. And then I'm also releasing a coding for pentesters book which is coming out in October that is going to go over a lot of the Ruby skills that you may need if you're interested in picking up the Ruby and also talking about how to build Metasploit modules in general. So if you're interested in sort of helping out with the Metasploit project, you think it's cool, there's just some resources that can help you out. So questions. No questions. That's kind of awesome. Well, thanks for attending. And oh, question. So the question was, was I using live networks or test networks and do not run into questions or do not run into problems where people are filtering broadcast and multicast traffic? And the answer is yes, because Defcon is actually filtering broadcast and multicast traffic through their networks. A lot of the stuff was tested with live network data. And some of the stuff was test, but most of the bug fixing was done with real stuff that I saw on the network. And for wireless networks, more and more people are filtering. But for internal corporate networks, I don't see a lot of that. It seems like good network segregation is still a problem for corporate network. A lot of the time it's just convenient to give out, you know, a slash 16 for a network just to make sure you don't run out of IP addresses. So that really extends the broadcast domain. And you may only get, you know, certain portions of a network, but you still typically see quite a bit of broadcast traffic. Anybody else have any questions? The question was, so for some of the packets, they didn't have an IP address, so the MAC address was shown. And that's right. So as part of the DHCP stuff, you don't necessarily have to have an IP address to be sending DHCP information out. So for that, I basically created one because of limitation with the Metasploit framework. It doesn't really let you very easily stick in notes without it being associated with something since a lot of the database portions are relational. So the MAC address seemed like a good one to use to make it up. So to determine which MAC addresses are passively watching the network? So there are, but the question was, is there a way to tell who's sniffing the network? And there are, but it requires sending out traffic. I believe that EtherCAP has a way of looking at who's doing men in the middleing and who is doing sniffing on the network. And there are some packet tricks to do that. I think that EtherCAP is probably the best place to look. And if anybody else has any recommendations, maybe they can help out. But I think that that's it for our questions right now. We're going to the question and answer room afterwards. So if you're interested in chatting more, please feel free to join us. Thank you.