Kevin Burgess - Malware Proliferation vs Microsegmentation

Thank you. All right. Uh, thank you, Glenn. Um, next up we have Kevin Burgess. Good to go. Thanks. Awesome.

Good morning. First, thanks Robert and the team for letting me come in. Um, so I work for somebody that you probably never heard of, and I'll talk about that later. Uh, I've been doing it a little longer than Glenn. I'm 30 years uh in this industry which makes me two things. One, I've seen a lot of change and I'm old as old as dirt. So, um that's what I know about 30 years. I have uh wor I started my career in in uh the late 80s working for a small computer shop in Halifax and then from there I've worked for SI's bars manufacturers customers and and now I'm back on the on the on a

startup side. Um so what I think what I've learned over that time is there's there's a there's always change and there needs to be change and if we don't change we die. like we're like sharks and we need to swim. So when uh when I joined this this latest startup, it uh it opened my eyes to a lot of things that that uh are changing in the world. Uh I've known done work with the cloud. Uh in one of my last roles, I did a complete cloud migration and uh it this is something we all need to talk about. Um we all need to understand where how cloud is affecting our lives. But from a from a networking

perspective, because that's what I've done for most my career, it's it's about how do we protect ourselves and do it differently than maybe we've done it before. So I don't normally present at a lot of um events because it's not really part of my role, but when I did a besides in Halifax in earlier this year because this was super preval prevalent in the industry and I want to get it out there. So, what I'm going to talk about is is um how does how does malware propagate through our companies, but not only malware, just breaches overall and how do how do these things happen and then what can we do to to help prevent them.

Glenn gave a really good talk on on the overall threats and I think we all just need to know that they're out there and malware uh remote access breaches. Is there anyone in the room that believes and we just have to accept the fact that it's no longer an if it's a win. He can't compromise this system that he's on. So, because it's a flat layer 2 network, he's going to then pivot and he's going to look for other targets on that layer 2 network. He's going to scan them, find one that's vulnerable, and then go take control of that system. He'll find the vulnerability, he'll exploit it, he'll escalate his privileges, and then he'll be able to do

whatever he wants. He can download ransomware, he could go on to another system and use that. This second system is not as well patched as the first system. that's why he's able to take control of it. And we all know we have in most cases, most organizations have those systems that aren't as well patched. Why? Um, I can tell you I've been in situations where we had a, believe it or not, a physical security server that was running on Windows 7 because the software wouldn't run on anything but Windows 7. Had no choice. So, was it patched? No way. Um, Glenn mentioned IoT devices. IoT devices generally don't get patched like the rest of us do with our systems.

Um it just doesn't happen. So they're typically very vulnerable. So we all know they're out there and sometimes we just can't do anything about it. So let's see if how this runs. Hopefully it runs well.

Quick. Hi everyone. Chris Tristan here with Nyall and I'm going to go ahead and run a quick demo of what could possibly happen on a traditional layer 2based network where you have multiple users and devices uh on that local LAN on the same IP subnet. Now the first example of what could possibly happen is you have a user who becomes socially engineered downloads some application that uh they're not exactly sure what's in it and they go ahead and uh run the application. So when that application is run what uh what could typically happen is there is somebody from the outside um hosting a service that will terminate these reverse shelves. So I will go ahead and run this and right away you

can see that because I ran that application on that Windows workstation it is running a process in the background where it has essentially opened up a reverse shell all the way back to my server here. And now I have established a backdoor access. So the expectation here is that this workstation is pretty well patched. But what you're looking at right now is that I have actually through this reverse shell gotten access to the local command line prompt of this workstation. Now, if I, you know, if I wanted to, I could dig a little bit deeper and, um, you know, look through the directory. And right now, you can see that I'm sitting directly in the downloads

folder. But what might be more interesting for me is if I were to back out of this shell and try to get the elevated elevated privileges on this system. Now, because this workstation is patched uh pretty well, it's not going to be very easily exploitable for me. Uh so, what I'm going to do is try to find uh another workstation or scan their network and see what else might be available. So something, you know, fairly simple is just going into the shell of that workstation and just taking a look at what might be available by running a IP config, just learning what network they actually sit on. And then I can actually, you know, do something like an

ARP and see what other workstations might exist. And right away I can see that there is a workstation sitting adjacent to this one. on the with an IP address ending in 20. Now, um I could run some additional port scans. Uh but there's really no need to. I'm going to go ahead and try to check if that workstation is vulnerable. Um but I'm going to use the workstation that I'm in right now as a jumping point to do so. So this would be an example of lateral movement which is too easy on a VLAN based network and very hard to detect especially if that network is uh further away from a border firewall in that customer's

environment. So let's go ahead and do um some lateral movement here. So I'm going to go ahead and exit out of this uh session out of this shell. Then I'm going to background this session that I'm in. And I'm going to go ahead and add a route to my Cali workstation to access this 192.168.10 network through the session that has been established. So if I just want to be I just want to make sure I gather the right session. So here I have session ID of five and it's sitting over there on the 182.16810 network. So I'm going to go ahead and do route add and I'm going to go ahead and type in [Music]

the network that I'm looking to scan. Go ahead and type in the net mask. And then I'm going to tell it to reach that network through session five. Okay. Then I'm going to go ahead and search for a port scan tool. And then I'm going to go ahead and use the fifth option to do a TCP scan. And then I'm going to go ahead and set the remote host. And because I know it exists based off of the shell access I got earlier, I'm going to go ahead and scan this workstation 192 168. The idea here is that it's widely available because um I can access it right across that same VLAN base network. There's really no controls for

me to to stop me from doing that. I'm going to go ahead and run this scan and find out what ports might be open. Okay, so that's interesting. Right now I can see that RDP is open through port 3389 and some version of SMB is open. So now I'll go ahead and search for the eternal blue because I uh exploit because I know that that will utilize port 445. I'll go ahead and check if that machine is indeed vulnerable by scanning. We'll set the remote host to that workstation that is sitting adjacent to us here and we'll run the scan and check what the workstation uh reports back to it. So it says here that it is likely vulnerable, meaning it

is running an older software version where I have a great chance of exploiting this machine successfully and gaining elevated privileges. So I'm going to go ahead and run option one to try to use this payload against it. So going to set the remote host. We're going to go ahead and try to hit that same workstation and let's go ahead and run that. Looks successful so far. We have established a session with it and we're now trying to exploit this workstation.

And just like that, we have established a interpreter session on a second workstation that is adjacent to the original workstation that we have gained access to through that reverse shell. Now, what is interesting about this is that this workstation was not patched. So, as you can see here, I have full access to this system. And if I want to access the shell further, I can and I can essentially migrate any process and run uh you know further exploitation against this device. You can grab screenshots, access cameras, run keyboard scanners, etc. So just to reiterate the point uh one more time as to how this demo went is the two workstations are residing next to each

other. I'm going to stop it there just because he's just going to recap what we did on a standard layer 2 network. All he did was run IP config ARP minus A sees everything because that's the way Ethernet works. Ethernet says everything is out there. I should be able to see it. The problem with that is if I can see it, I can do that. So, for the most part, this is the way we've built networks for the last 30 years once we started using Ethernet. If you're looking at real defense in depth and you've looked at I got my workstations covered, I got my firewall covered, I'm doing EDR like Glenn mentioned, why are we leaving our

networks like that? So, the company that I work for is called Nile. Uh, we're a John Chambers startup out of California. Hopefully, most of you know who John Chambers is. Um, he was former chairman of Cisco. We came out and we said in 2018, there's got to be a better way of building networks. There's got to be a better way of managing networks. So, we are a pure networking as a service organization campus. We build and maintain and manage campus networks for our customers. Higher ed um huge in the US. We actually have zero presence in in Canada except the company I used to work for in Halifax. I deployed it in December 2020. They're still running it.

So no sales organization in Canada today. Um all based in the US. But it's important that you understand why you know what we're doing and what the difference is. So we are networking as a service but we built this in a different way. We have no full layer two doesn't exist. You can't do what Chris was just able to do and I'm going to show you that. So exactly the same setup. The only difference is in the middle we have our network. It's called a Nile service block. It's essentially a network that we deploy and then manage on behalf of the customer. Everything else is exactly the same. Same workstations, same OS, uh same upper

level, same layer three, everything. The only difference is we took out the legacy layer 2, layer three network and put in a layer 2 network of our own. We're going to try to do the same things. Exactly the same conversation. We can't stop that malware or that attacker from getting in. That's not us. We don't do that. that if they can get to the internet, bad [ __ ] can happen. Sorry, I said [ __ ] Sorry. Um, I'm a new philanthropist. It's probably rape, right? Okay, good. Um, that will happen. So, we already said that you're going to get hit. You're going to get breached. You're going to get malware. So, we know that exactly the same uh thing. We'll do

that. We'll do this and we'll do that. This is a screenshot because we we I can't show you an arc minus a because it it won't work. This is showing those systems. This is our dashboard to show a customer what's on their network. This is just a a quick screenshot of a Nile network to show you these these workstations do exist. This isn't this isn't magic. This isn't me, you know, making this up. Those workstations exist. And what we're going to do, they're on the same exact subnet. So, if you look, they're all on the 1023 subnet. So, they're all adjacent. They are all on the same subnet. Hey everybody, Chris Tristan here again. And in this demo, as a followup for the

last, what we're going to do is run more of the same type of attacks and reconnaissance on a LAN, but the key difference is that all the devices are now plugged into a dial based node. So what you're looking at right now is the client view of the NY dashboard and you can observe that all three Windows workstations are plugged in via wired into the same segment and are residing in the same IP seg IP range. So this is a slash24 subnet mask and therefore very similar situation to the last where all three devices are adjacent to each other from an IP. The difference here is that in the Nile network we have client isolation

running by default without any configuration and we provide full firewall visibility for all client traffic no matter where it's destined. So let me go ahead and give you an example of that by kicking the demo off. I will go to the workstation that was located on the 12 subnet mask. I will launch the reverse shell application just like I did on the last demo. I'll head over to my Kali Linux server and I will run my multi- handler and the shell session is established right away. Now like I showed you before this 102341.12 uh workstation is this device right here. So let me give you an example of the power of our client isolation by default

embedded native behavior. So I'm going to go ahead and establish a or jump into the command prompt of this workstation. Then I'm going to do a just a basic IP config to understand the network that it's on. And like I said earlier, it's SL24. In this case, 1054.1. Now, I'm going to go ahead and run an RP just to see what else I can discover on the demo. Now, right now, as you can see, there's really nothing there. Um, but unlike the last demo, what I'm going to do is run a wider sweep of scans. So, I'm going to go ahead and exit from the shell, and then I'm going to background this session. I'm going to go ahead and use

that same port scan tool that I did earlier, but in this case, I'm going to widen my suite because the workstation in this case has not contacted any of the other three workstations in the network. So, it wasn't easy for me to identify them. So, let's go ahead and use the TCP scanner, which is option five. And then I'm going to set the remote hosts for the entire network that those workstations are sitting on that that they mask and then I'm going to say that we're going to get to this network through this workstation that I have established shell which is session. Now before I forget, I do have to add a route so that my Cali

workstation knows how to get to that SL24. So I will go ahead and do that now. And that's actually session 8. And then we're going to set the remote host. I actually backwards on this. We're going to set the remote host to the entire No. Okay. So with that being said, uh the expectation here is that I'm going to send out a port scan and I am looking for vulnerable vulnerable ports from ports 21 through 23, SMB and RDP. So a little bit more of a targeted scan for these ports. Let's go ahead and run this.

Now, we discovered that we're running SMB on our own IP, but we haven't discovered anything else just yet. And I'll kind of give you the spoiler alert is nothing's going to show up because by default on a Nile network, we are isolating all client traffic. So just a reminder if I go back you'll see that there's other active workstations 32 and35 yet I am not able to discover those clients because of the native client isolation without any configuration. Now, if I dig in a little bit deeper, I can actually go to the upstream firewall and discover that these port scans are taking place. So, really quick, I'm going to go ahead and click on a do run a quick

filter here. And the IP that I was using was 10234 1.12. Now I'll go ahead and filter. Now check this out. In the logs you see that this workstation was just being used as a device to perform a port scan which is a form of lateral movement. But the firewall was able to actually see that this that this traffic was uh being generated and that this type of activity was taking place on essentially every single session. And remember I scanned from ports 21 through 23. So here you can see all three ports in the 20s. I scan for the RDP and server message block and all of those IPs were hit as a part of that

scan. Now typically um we would we would have finite policy to allow some connectivity but in this case we are denying all to show you exactly the level of visibility that the Nile network is providing to the customer's firewall. What's even uh better is that in the logs, if I were to click on threat, we should see that right off the bat, we are showing that we're able to discover that there is a potential threat because of the port scanning activity that is taking place. So, this is just an example of the level of visibility that we're giving you with zero configuration embedded behavior on the Nile network. So, I don't know about you, but

I've never seen a firewall pick up layer 2 connectivity between two workstations on the same network because normally in the networks we build, the firewall sees when traffic leaves my subnet, not the traffic within the subnet. Now, can this be done with other technologies, other vendors out there? Absolutely. Sure, you can build this. We do it out of the box. Zero config, zero touch. It just happens that way. So, what did we do? We did the first thing that all worked. Then we tried to do the identification, the the the the lateral movement, not going to work. Lateral control, not going to work. So, this is this is again a tool in your kit. Like

I'm not saying, you know, get this, do this, and you're going to end up with a perfectly secure environment. Not going to happen. We need defense in depth. And this is just another way of doing it. In fact, we're not a security company. We don't we don't do this as and come out and say, "Yep, we're going to we're doing it because we're we're building this." We are a networking company that's built a secure network. 30 years ago, if we had known what we know today, we would have built networks like that. that would have been the way we would have built them because they are inherently more secure. So we did a social engineering,

we did network reconnaissance, we did pivoting, lateral movement, we exploited the idea being with what we do on our network, this new way of building a network, your your blast radius for that infection or that or that attack or that breach is literally now one. it can't get past that workstation without the traffic going to a layer three device at the top of the network. Now, if you'll if you if you go on that layer three device and you say allow all, I can't help you. You have to be able to put some type of control at that layer in order for this to work. And people also say, well, I I I do need

some things on the same subnet to talk to each other, printers. Great. We can do microg within our network to allow that. But you don't need every workstation to talk to every other workstation. That that that ship sailed. The only real reason for my laptop to talk to somebody else's laptop on the same segment is malware or a breach of some kind. If you don't believe that, you know, we can talk about it later. But we we do allow some things um security cameras talking to a security server. Totally makes sense. But generally traffic on the network should stay on the network.

So what did we do for our for our our our our breach detection, our malware detection? We've now identified. We know where that the infection is. It can't get anywhere else. It's on that one device and we isolated out of the box. It's already happened. Your isolation's already done. So you don't have to worry about it. This isn't going to work for everything. It's not going to work as as Glenn mentioned for some versions of malware because that traffic looks like normal traffic to the network. you have to have something like uh behavioral heristics that understands that this workstation shouldn't be talking to that server over there. That's going to happen. So, you have to have the EDR

stuff, but on the same subnet, we can do this. So, I've got a couple minutes left. I'm going to just talk quickly about zero trust because everybody wants to talk about zero trust and everybody loves zero trust. Zero trust to me means you don't trust anything. That's what zero trust means. Empirically, don't trust anything. The problem with zero trust is it adds complexity including distributed management. So some people say I'm going to put zero trust. I'm going to put uh management points or access points all over the place. That's a challenge. Um that takes time and manpower. That also means you have um maintenance problems because you've got all these extra devices. Who's going to manage them?

Who's going to update them? Who's going to do all the work on them? Uh troubleshooting becomes crazy. You've got levels of control control points at different layers of your network. Well, how does that policy work? Who manages all that policy? And then it costs a lot more money. Generally, we're doing everything out of the box. So, the way we've built it is that that network now has a single point of control. It's the layer three at the top of the network. That layer three controls all the traffic. Essentially, it sees and more more importantly, it sees all the traffic. So, in general, firewall vendors love this approach. If you've talked to a firewall vendor, they

generally say, "If we don't see the traffic, we can't control the traffic. We can't policy the traffic. You got to let us see the traffic." So, that's why you put in taps. You put in a tap here and a tap there and a tap here and a that's expensive. So what we're saying is our network ingests all the traffic and then sends it to a layer three control point a single layer 3 control point or obviously high availability but all the traffic is seen there. Therefore that firewall vendor can then say yep I see everything I can help you control it. So that's what that's what zero trust isolation means. Zero trust access um essentially is we don't allow

unauthoriz unauthorized access to the network. There is no such thing as an open network in the Nile world. You have to be authorized. So and the last thing is the network itself that we build has basically being a black box. No SSH, no console port, no way to physically attack one of these boxes. When we put it in, we own it. We manage it. I think I'm on time. Yes, somewhat. Good. Couple minutes. I'll take questions. Anything Anything you want to throw out um about what I've talked about? Talk about Nile, where we come from. We can talk about, you know, what we showed. Anything was interesting questions. Come on. Yes. uh how do you uh protect the

physical security you mentioned that so on the on the physical we don't we from a networking perspective all our all our devices are secure black boxes so there is no console port you can't walk you if you even get access to a closet where a n network is deployed you can't plug a console cable in doesn't exist and when you're on the network itself you can't see any devices you can't and there is no SSH so nobody locally can SSH to a single box and do bad things on it. Um, the other thing there's there's no config. There's literally nobody typing in uh host name blah blah blah IP address blah blah blah. That doesn't

exist. We don't we so there is no way to fat finger something inside this network. So we all know that how to how to bad people get in somebody leaves something open. Well, there is no config on our side. Doesn't happen. Everything is automated. So built in the cloud um built from the ground up with automation. It's a just a different way of building networks that we've never done before. Now again, campus, yes, data center, we don't touch. We're not going to go into a data center and say, "Hey, let's build this in there." It's way too complex to build this type of network. But in a campus, in a LAN environment, wired and Wi-Fi absolutely

100%. Um, I was telling a story. We have we have a a university we deployed at in in Buffalo, New York and uh we deployed across their dorms just in mid August. Students came back in in September and I had a call with their VP of student rel or student resources or student something and she I've never had this happen in 30 years. She gets on the call and she says immediately to me first thing she says I love Nile. I didn't prompt it. I didn't say I okay thank you I guess. Um I said why? And she said this time last year students moved into the dorms we had between three and 500 trouble tickets in the first 24 hours

with not things not working students not getting on whatever. This year with the network that we deployed zero in up in two weeks two and a half weeks and zero trouble tickets when the students moved in. So, it's a different way of doing it. Um, and uh, you know, I'm I'm pretty happy that I got involved. I mean, it's it's pretty cool. Other questions? Got to be somebody over here. You guys awake? Yep. Y up. So, you said there's no opportunity for fat fingers, but I mean, somebody's got to configure that. Well, all these workstations should be allowed to talk to the printer, and this camera should be allowed to talk to the security server,

etc. Yep. um is that just meaning that the person who's doing that operation is then you folks so so no we we give you the opportunity to set up policy so what I meant by fat finger is more config so um putting in uh uh your OPF config or putting in um uh config at the switch layer itself the policy and the microseg that's all on you that's on the customer so we own we're essentially like AWS for the on-rem network. We give you the infrastructure. You build on top of it what you want. Your SSIDs, your segments, um your micro seg policy and that configuration only works if we can connect externally. Yeah. So everything's in the cloud. So

you you so the way it actually works is when our switches come up, they build an SSL tunnel back to our knock and then we ride that SSL tunnel back to get config on those switches. So when you're configuring things, you configure things in our in our portal interface at the knock layer and that gets pushed down to switches. Does it require an active connection? So does the SSL tunnel have to be up in order for your policy to be forced or is it a download? No, once it's once it's down, we can you can't change it, but if the SSL tunnel drops for some reason, policy will still work. Same as same as users can still conf uh if even if the

internet goes down, users can still work. We're we're kind of built on the premise of the internet goes down today, what the hell are you doing anyway in most cases? And doesn't the underlying structure for this like still exist in private vans? Yeah, in in some ways it kind of does, but again much more config intensive. So, um, and again, you can do this with with Cisco DNA. You can do it with a bunch of different products, but I defy you to do it in a way that's zero config and takes no time to do it. It, um, I because I've done it and it takes manh hours, a lot of manh hours. Um, so

it can work. Yes, there there are multiple applications out there, but because we built it from the ground up to be this way, we don't have to have that. Yep. From a geographic perspective, is hosted. So it is so the the knock itself is hosted in US West AWS. Um the the the data traffic never traverses that. So your the only thing goes into our knock is the control plane. So your data traffic stays local. We don't have to do anything with it. We don't touch it. Your traffic your your site. But what we bring up because we're managing the network itself. The control plane the control plane data gets sent up to us as

well as metadata uh on the traffic. So understanding the being able to see the uh the data we then encrypt that data at the uh AWS knock and you have the ability to decrypt it with your own keys. So yes uh I have had people talk about you know where's my data? Well your data stays local. The only cloud is is metadata control plane. Welcome. Yes. Are there specific brands of switches or that you guys use? All our own. We built it from the ground up. We started four years ago and said, "We can't build this on top of somebody else's platform." Um, we couldn't have done what we did at that university in Buffalo with somebody else's platform.

We had to build something that we knew would just work. The key is we don't get paid unless it works. It's a service. So, if the network doesn't work and it goes down, we don't make any money. We literally charge you a subscription fee for the network. So we had to build it so that we were 100% confident we could make it work. Which is why we we we started with a thousand over a thousand data points and said what are the things if we could build a network in a better way. What are they? Well we have no layer 2 spanning tree. Span tree is great. If you know networking span tree works great. You

have multiple links. One link goes down other link comes up. It's great. But there's a learning period right? You have blocking. You have learning. You have forwarding that happens within span tree whether it happens within a microcond 10 microsconds milliseconds whatever there is still downtime for your network when spanning tree kicks in. And we said we're building a brand new network. Do we need spanning tree? The answer is no. Everything passed at layer three. All the links between switches are done at layer three. So there is no requirement for layer 2 spanning tree. So another thing checked off the box. Can the network go down because the land a layer 2 spanning tree convergence? No.

So again we built it for that manner. Anything else? Yes.

So DHCP will work direct right out of the box. Uh but you have to configure your DHP server. Yeah. So we do layer three. We do layer three forwarding of D basically proxing of DHCP. So your DHCP sitting on server over here. We basically proxy it in. So we take the DHP request in proxy at layer 3 directly to that DHP server which is great works fine. Um the other thing we've done is we've created our own DHP service. First one cloud-based DHCP server. So if you've got a site out in gander that you don't want to stick a DHP server in we will offer you a service that says we'll run DHP for you in the cloud. So your

users will get a DHP server or DHP DHCP address from us based on a subnet that you specify. Anything else? Going once twice. Okay.