 Next-gen firewalls for threat hunting. I'm Sean Wallace, a cybersecurity research strategist. For five years, I've invested time designing and implementing a passive next-gen firewall. This has led me to understand that it can be used as a great threat hunting tool. And in this talk, I'm gonna spend some time showing how you can achieve visibility with these next-gen firewalls, test new features to help mitigate risks from your production traffic and apply bleeding and functionality signatures to those next-gen firewalls to get some early visibility and enhance and compliment your threat hunting tools. First, a bit about myself. Again, I'm Sean Wallace. I'm a research strategist at the top U.S. Bank. I'm a network security domain specialist. Things like firewalls, IDS, threat hunting tools, packet capture tools, and email are things that I have a lot of history and experience working on. I'm an advisor to Threat Intel as a service company by the name of Silent Push. I'm a DEF CON goon and a Black Hat volunteer and I live in the San Francisco Bay Area. So how did this come about? As I was looking at next-gen firewalls, I noticed and observed an operational risk that application ID could potentially cause an impact of production traffic. And I started to look at ways to mitigate that risk. A traditional firewall has firewall rules in what's called the five tuple. Looking at source IP, source port, destination IP, destination port, and protocol. With next-gen firewalls, we add application ID as well as some other features, such as user identity, which can be used to write those firewall rules. So then this example that I'm showing below, we can apply that only HTTP proxy traffic can be allowed through a rule, meaning application traffic matching SSH could not, thus you can block SSH traffic. You could of course also put in a rule above that says deny SSH traffic for the application. So now that I have this application logic, what happens if that logic changes on the firewall? Applications are ever-changing and what if the firewall either can't keep up or what if the firewall starts to think that that application is something else? We had a similar incident that happened very early on where we had some impact with a tool, just something such as HackX, where the application logic of that changed in the firewall and started to block the traffic. So again, we considered how can we mitigate that risk? And I thought of putting a passive-next-gen firewall side-by-side that we could update quickly and monitor such changes. You might ask, why couldn't you just do this in a lab environment? Well, with a large network with so many different applications, it's hard to test every single one of them in the lab. So having this allows us that luxury of being able to see what's on the production network and observing those changes, as well as nothing ever works in the lab like it does in production. So the solution I came up with again is let's deploy a passive-next-gen firewall. This gave us that mitigation to observe application IDs as well as now we can test new configurations, new features, new signatures or deploy custom signatures or new versions. The added benefit of all this is we can turn on all the security features, the passive security features we want and get the most value of our next-gen firewall to help complement our threat-having tools. This isn't necessarily a brand-new idea. This has been done with IDS vendors before. A lot of them call these their various lighthouse systems where these systems are observing traffic on the network and reporting back. So they roll out these new signatures to various lighthouse systems and make sure that they aren't seeing various false positives before rolling them out. Now that a lot of systems are moving to cloud, they pretty much do this without even having to tell you. But you might ask, don't I already have other threat-having tools? What's really the benefits or why do I need this? Well, you know, I'd like you to ask how many of your threat-having tools have application ID intelligence? I know we have quite a few and they just haven't gotten there yet with app ID intelligence yet. Unless they're from a big vendor that already has this baked into an action firewall or they've been able to port that over to various tools. Merging threats, how often do these various tools push down new signatures or new content? And are they at the pace that you would see an IDS box or whatnot pushing content? Most of these tools don't have IDS signatures themselves either. Most package capture systems I know of don't either, although some have been investigating going in that route. File movement, I know a couple packet capture systems as well as other threat-having tools which have issues decoding various files on the network if they are non-web apps. However, what I've seen with the next-gen firewalls is it's very key to be able to decode that as it's needed that for some of its feature and functionality. Searching placement, you may decide that where I have my firewalls and where I have my package capture or other threat-hunting tools, maybe I have them at different choke points or different locations so you can get some added benefit out of this because of that. And encryption, surprisingly, there's still quite a high value without encryption here. So I think that's an option to consider. Now I'm gonna look at a couple of different architectures and discuss them that you could deploy in. In this one, this is without decryption. You can see the user traffic is accessing either a router or a packet broker, and then that traffic spanned off to your passive-next-gen firewall for inspection. However, your production traffic, your active traffic's going through number three here and flowing out to the internet as normal. Here we have one with decryption where we add that packet broker to parse over and decrypt that traffic and then send it back to the packet broker. In this case, the passive-next-gen firewall is getting that decrypto traffic but your active traffic is still going through next-gen firewall inspection as normal. One thing I'll add here is the next-gen firewall can also do encryption and wouldn't it be great if instead of having this added box of a packet broker that the next-gen firewall could just span that traffic over? This is something we definitely have been working with various vendors. Figuring out if we can do to help simplify this diagram and reduce the number of hops traffic has to access and the number of times we have to decrypt traffic. So the high-level concept here is with all of these features, can we deploy a passive-next-gen firewall essentially as a pre-prod environment where we can see live traffic but also leverage all of these benefits of features, functionalities, and versions coming from a next-gen firewall? Again, you can have early adoption of hardware, software, new threat signatures, new features, and new functionality. The one other thing I really like about this approach is most threat tools or packet capture systems that I've worked with really have leveraged a custom UI where you're always in that UI doing your hunting and looking but next-gen firewalls are really good about logging and we're interacting with a SIM. So this gives you the benefit of giving all that data over the SIM, leveraging reports and alerts and anything that you have in there as well as other logic or other sub-searches that you can enrich your data with that you may not get in other threat hunting tools. So now we're gonna go through and kind of look through some of the features and some of the things that stand out. Obviously the firewall logs are gonna allow you to see all the traffic and this is important because if you don't enable them you'll maybe only see all the threat traffic. That can be good or bad depending on your solution. If you want the app ID enrichment though you're gonna need all of that traffic logged depending on what your other firewall solution is this could either be new traffic or just enrichment or a different source depending on again what that other traffic is. If you do have other firewalls this traffic can also be duplicate. That's something to consider because it's essentially is doubling your log size or even more if you're starting to enable a lot of features and functionalities. But if you really wanna compare your application ID traffic it's very important to enable this. You need to be able to see if the application traffic between your passive environment and active environment are the same. I should note here that various vendors log differently. Some of them log at the beginning of the session some of them log at the end of the session. The end of the session you're gonna find out how did the session terminate? How many bytes were in the session? Sometimes you'll find out and whether it's in timeout or not. You don't necessarily get that in the beginning of the session data. All the firewalls do allow you to enable both logging at the beginning and end. So this is a strong consideration that maybe you want that data to be able to really kind of help you. Application ID. Next in firewalls, introduce application ID. Now they're giving you more context and just the destination IP and a port. They're giving you what is this application and what is it doing? So if you look at the example here I have some sample common applications or uncommon I should say. You see SPN go, you see Facebook social plugin. You see Google Cloud storage download. You see the context of what that user is doing whether downloading or uploading. That can be very valuable in threat hunting. If you wanna start writing your searches to filter on people uploading data or perhaps downloading data. Then you can also start to pair that with your various threat data to see exactly where it came from and what they were doing. So some ideas how I use the application data is looking at those rare ones. I always like to see what am I, what would I expect on my network? What am I seeing that's different or not expecting and why are people suddenly going there? You can also leverage the context that I mentioned to see what people are doing within those applications. Maybe they're uploading when they shouldn't be or maybe they're uploading to a place you didn't expect. And then of course you can look at various anomalies. This is very important as you can start to see those sharp increases and this can lead you to various DLP type information or perhaps C2. In this example I'm showing, we're looking at GitHub traffic. And again, you can see that context. This data is from Palo Alto. It's publicly available and it's totally free from Applopedia that PaloAutoNetworks.com. Most firewall vendors have this information for free. I just picked Palo. I kind of like the interface of how it shows and it made it easy for me to talk about. So in this case, think about this if you wanna write the same content on another thread hunting tool, essentially you probably could do it, right? We've done this before in various packet capture systems where I wanna focus on uploading or posting of information. But if I'm looking for uploading, I'm looking for posts but then I have to go and do additional legwork. How do I distinguish between a post and an upload here or edit of a GitHub system? Here the next firewall vendor's done all the legwork for you. So it really can simplify and you can focus more on the content rather than getting the content. And another example here, I'm looking at SSH. You can see in SSH, you can start to see how you can leverage looking at the uncommon ports. You can see the ports I would expect to see on my network, 228022 and some of the 2222. Now I start to see some more of the uncommon ones or ones that I'm not really expecting. The one that stands out to me obviously is 8080 because that's my web proxy. That means somebody is essentially probably trying to handle a SSH. With any of these, I can now pivot off the IP addresses that are provided and perhaps see what other things they're doing or what other applications they're triggering or maybe threats. And that's very valuable. Moving on to IDS threat and malware. I think they greatly speak for themselves. Obviously, IDS can be used to identify potential threats. Malware inspection can inspect files traversing from malicious malware. You can set up immediate updates, as I mentioned before, and as soon as zero-day threats come out, start to monitor those. Hunting for those new vulnerabilities, you can find out internal threats, perhaps new networks that have scanning that you didn't expect to or who are the people out on the internet who are really hitting you with zero-day scanning. One thing I would mention, be very cautious of enabling low and informational signatures. That data can be an overwhelming noise. The reason for that is a lot of those are just meant to identify various types of traffic, not necessarily meant to look for threats or threat signatures. One example of that is we had enabled all low and informational when we first started it out. And one of the signatures was identifying various active directory traffic. It was essentially saying, hey, there's an active directory server here. There's an active directory server here. Every single packet. And I'm like, yeah, there's supposed to be an active directory server here. So it's just one of those that I'm like, okay, I'm not sure that I needed to know this information, but it was an awful lot of noise and also had a huge CPU impact due to that. Moving on to URL filtering categories, connection firewalls also have the capability to log all URLs and then take those URLs and match them to a category. That can be very beneficial if you're using a web proxy. You probably already have this functionality, but what if they don't match? In this example, you can see one of these is not like the other. Here we have three public category sites, Cisco, Checkpoint, Broadcom and Palo Alto. And three of them are showing this particular site as shopping, whereas we have the fourth one, Palo Alto, showing it as malware. I'm sure if you talk to each of the vendors, they're gonna say that their threat intelligence probably better or comes from a different source than others. However, and they probably have more insight than others and that's perhaps why one is different. That's for you to decide, but taking as many different sources as possible could help you with better enhancement of your threat data on your network. Moving on to file protection, this is my favorite part. File protection is allowing to see you files traverse across your network, not just for web applications, which I think is very exciting. You can start to see other traffic, such as SMB and other applications that leverage this. In this example here, I'm showing you how, just looking at the file name, searching for passwords are essentially, you're seeing various file names that have passwords in them. These obviously look very suspicious. In the first case here, you can see that's over SMB, B1. B1 is not encrypted. So I can go in my package capture tool, pull this file out and guess what? I have some 2021 passwords and probably so do other people if they essentially are trying to pull these files off our network. This is just an example that I'm showing here, but wanted to kind of give that of seeing how this could be valuable. Further going on this example, again, I'm showing Palo Alto's Appliquea here, where it distinguishes between V1, V2 and V3. This can help you search on your network and find out, do I had V1 on my network or I shouldn't? And you can track down those various systems and have them cleaned up. Then you can extract those juicy files from the system. One thing to note is, and I learned this, I didn't necessarily know a lot about SMB when I went down this path. So this was a good learning experience for me. The file pointer in SMB is not encrypted. So even in V2 and V3, I am seeing that file pointer so I can see file traversal across the network. SMB V3 and such also introduced multi-channel. I put a link in here that is a really good breakdown of what that means. However, the long and the short of it is it uses now multiple sessions to exchange files. So we lose some of this visibility. Various vendors are still working through support for multi-channel. So in using this, in the future, we will be able to see the same visibility we have again and that I think is very exciting. I do know there are some vendors that already have this rolled out. So I would encourage people to look into this if this is something that you know little about and maybe missing visibility on your network. Moving on to DLP, there are DLP policies that you can't enable. In my experience though, I leave that to the experts. I attempted to turn this on and it was nothing but noise. It was gonna be very difficult for me to write a lot of these signatures and a lot of the advanced DLP tools already have better detection than signatures that I had the capability of writing. I would encourage you to partner with your experts and see if maybe there is some benefit to do this and maybe it's worthwhile to reach out to them and chat about it. Moving on to email. Email is also one of the weakest areas. The reason for this is the next-gen firewalls don't run as an email server. They run simply as a act that we're gonna pass the traffic through. In an email server, you're terminating the session, gathering all that metadata and then starting up a new session. It's very possible for the next-gen firewalls to capture this information. I just don't think they've invested the time or effort nor maybe do they want to do this. For that reason, there's been a lot of parsing issues with the data that I've seen in my experience. I do have a lot of experience on the email front and I've noticed the log messages are just so much better coming out of the email gateway that I tend to result in looking at that. One area I can note about this though is that you can leverage email for looking at malware and threats that are coming across email for what data that you do have. So that is very valuable as another source. Maybe it's a different type of sandbox, maybe it's a different type of technology, more sources the better in this case. Two other areas are DNS and user identity. DNS protections in most case are active protections on next-gen firewalls. So there isn't a lot you can do here nor a lot of value of enabling that. It requires you to actually point to the next-gen firewall then actively kind of take that data and do something with it. And if you have a passive environment, well, you can't necessarily do that. It requires that kind of active interception. In that case, I haven't spent a lot of time looking on that this and I wish that it was more kind of anomaly detection for a passive environment built in. User identity, on the other hand, is great. You can tie this in after directory and start to get a relationship of what your users are, what your user anomaly behavior is, and et cetera. I haven't spent a lot of time on this either because it requires somewhere to grab that database from. I've noticed that various different implementations do this differently. There hasn't been necessarily a common trend to do this and that's been one kind of turnoff for me on doing this. The other is, is it's an active connection and it's talking actively to after trajectory. That can be in a large environment that could be very impactful and have some production risk. So we kind of stayed away from that as well until we're a little more ready and active to look into this. Overall, I wanna say in conclusion, I really think next-gen firewalls have a legitimate place here for threat hunting. I really want various vendors to kind of take this seriously, kind of consider that, hey, yes, we may have a use case here that other people and businesses may find as well as a risk mitigation part for networks to make sure if they're a little scared or a little shy to get their feet wet because of these various impactful changes, they're all alternatives to do this. I also really wanna thank the community for letting me speak. I'd really love to hear from more people who have similar experiences or further interest in the subject. I definitely, as I said, I'm very passionate about this and would love to move forward myself with this. There are any questions, please let me know. Feel free to reach out. Thanks so much.