Tim: 0:01

Welcome to the Cables to Clouds podcast.

Serena: 0:04

Your one-stop shop for all things, hybrid and multi-cloud networking. Now here are your hosts Tim, chris and Alex.

Chris: 0:14

Hello and welcome back to another episode of the Cables to Clouds podcast. My name is Chris Miles at BGP Main on Twitter. I'm joined by my lovely co-host, tim McConaughey at Juan Goldbez on Twitter, and we have a very special episode for you today. One, because we have a great guest. Two, because it's Tim's birthday, so everyone say happy birthday to Tim. And then three, it is also election day in the US, so there's a lot of shit going on today, but we're going to have a good conversation regardless. So joining us today is Serena, aka SheNetworks. So if you've ever been on Network Engineering Twitter at all, you've probably seen Serena out there. She's pretty prominent, put out some good content. So yeah, welcome to the show, serena. Thanks for coming on.

Serena: 1:00

Yeah, thanks for having me.

Chris: 1:01

So, yeah, I guess maybe we'll start with you know, for those of those that don't know you, tell us a little bit about yourself, your background and where you are today.

Serena: 1:10

Yeah, so I started my career as a network engineer. Well, I would say that's probably the start of my professional engineer. Before that I had worked at like Best Buy, in the computer department. I worked at the Apple store, at the Genius Bar. I went to college, had a couple of internships, then I graduated college and became a network engineer working at Cisco, primarily focused on unified computing systems and other data center products. From there I went on to do data center design and then I went back to Cisco data center design, and then I went back to Cisco and then now, most currently, I work in the cybersecurity space as a penetration tester.

Tim: 1:51

Yeah, that's quite the path to follow there. So you started at Cisco in UC. So can I ask, were you in advanced or like, which part of Cisco were you working at with UC?

Serena: 2:07

Yeah, I was a TAC engineer. So I was yeah, tac and mainly worked on. I swear there was like a four month period where I only took severity outage cases on UCS. Ucs gets dragged into pretty much every outage because it's the thing that everyone notices impacted first. When you have all these virtual machines that's not working or like what's going on, and sometimes it can take a while to actually locate where the issue is. Yeah, lots of cases, a lot of severity outages. Yeah, it was very, very busy time.

Tim: 2:41

That's tech for you. No, no, no question there. Yeah, I used to work at Cisco as well. That's, that's always curious. And then you said you went to data center design from Cisco, so you went to like a VAR or different company or something that was doing that there.

Serena: 2:54

Yeah, I was at a different company. They did they were kind of like a software as a service provider for government agencies, and so I worked on data center design and implementation there. I wasn't there very long because Cisco offered me a deal to come back, so I came back and then was working as a technical lead on customer success data center for the Americas, and so that was mainly addressing people post-sales who might've had issues integrating new products into their existing environment.

Tim: 3:31

Nice, yeah, that's that's yeah. I was in advanced services before, just just before I left Cisco, working with a lot of the CS, css folks as well, so, but I but I, I was focused on enterprise and SD-WAN, so that, but I but I, I was focused on enterprise and SD-WAN, so that was probably. It's a big, big organization.

Serena: 3:48

Yeah, I referred a lot of people to advanced services Cause a lot of people will like open up a TAC case for like instructions on how to do things in, like training or, you know, configuration set up. But we're kind of more like a break fix shop. So definitely a lot of cases over to advanced services, that who knows what happens there? But that's.

Chris: 4:12

I was like all right, not, my config is broke because I don't know how to do it, so yeah, yeah, it's like T1. I'm like okay, well, I have a.

Serena: 4:22

I have a hospital that doesn't have any like all their systems are down, or I have this case and we're going to have to pick which one really needs the help at the moment. Because I think like the one thing for people who are not as familiar with tech is that there's actually very few tech engineers working on a specific product at any given time. Tech engineers working on a specific product at any given time. So when I was on, you know, in Richardson, at the location I was at on the UCS team maybe we had like 10 engineers on for like a four hour period. Right, we did have some like third party engineers that kind of handled more like oh, we're going to RMA a specific part or something. You know like those kind of easier low hanging fruit cases. But yeah, when it comes to like the severity outages and other cases like that, they're a little bit more complicated. There's really not that many people on staff at once.

Chris: 5:15

Well, yeah, so let's kind of dive into the topic that we wanted to get into today. So obviously you've had a background in network engineering specifically and you've moved into cybersecurity, specifically into offensive security and pen testing and things like that. So I'd like to understand a little bit more about what made you want to make that move from network engineering specifically into pen testing cybersecurity. Was there something specifically that kind of triggered that or your interest that went that way?

Serena: 5:46

Yeah, I would say that network engineering is fun, but it does get repetitive sometimes, right when you are really working with the same products, doing the same things, fixing things, implementing stuff, helping everybody else out. You know, putting out fires, and I realize it's like way easier to start the fires. And so I was like give me that job right Because it's fun and it's exciting.

Serena: 6:18

I think, coming from a TAC background, it's a little bit difficult to go into a regular network engineering job from there because one you're so siloed when you're working at TAC and then two you I mean, I was dropped into a new network environment a few like a few times a day, right, and so early on my career I'm like, okay, give me the next network, the next problem, this, this, this, and then, once you move into kind of a more regular network engineering role, it's like okay, this feels kind of slow a little bit and.

Serena: 6:51

I get bored super easily and you know, with pen testing I mean there's always something new to exploit, uh, new things to learn, and then also like again, I'm being dropped into new networks all the time. So, like, every time I'm on a test, it's usually a brand new network, a brand new environment that I have to learn very quickly to hopefully meet my objectives and satisfy the customer. And I think that kind of more fast-paced environment keeps me a little bit more focused and I find that to be a little bit more fulfilling for myself. I'm not really good at projects. I'm great at starting things, I'm terrible at finishing things.

Serena: 7:30

So you know working on a long project for me can get kind of like tedious. And then you know, with my, you know, the longest test that I've been on is two weeks. Our red teams can be a lot longer, but like, all right, two weeks, and then I'm done, I'm on to the next thing, and that, I think, is kind of better from just the way my brain works.

Tim: 7:48

Yeah, I think that's fair. A lot of people, like a lot of people that enjoy that, also enjoy contracting, like doing like 1099 work, if you will, where you know they'll take a small contract to come in, build something small, troubleshoot something, fix something, whatever, hey, and then same thing. Right, they get their 40 hours, 80 hours, whatever it is, and then they're out and on to the next thing as well.

Serena: 8:13

I'm a little intimidated by smaller projects because I have a lot of working knowledge of protocols and data center. But I would say I'm like a little bit more rusty when it comes to small business or you know more of like that end user side, that access layer. I'm kind of like whoa, like I haven't touched this in a while, and like spanning tree. You know, when I was working in UCS and data center, like you really don't deal with spanning tree at all, which was great. And then you know, I just memory working in UCS and data center like you, really don't deal with spanning tree at all which was great.

Serena: 8:45

And then, you know, I just memory hold it because I'm like I don't want this in my brain. I get that yeah. Getting back into like the access layer. I'm just like, oh, OK, well, there's a lot of things here, and then you have port security and you have just access, like you know, access control. So there's like a whole new layer of issues going from like that more of a campus small business design versus like a data center.

Tim: 9:12

So actually that's a good thing. I wanted to say with you a little bit, which is so. You know you started in network engineering. You're doing pen testing now Are you doing a lot of pen testing, like with networks, and if so, are you I? So it sounds like you may not be attacking the access layer. How does that work? What are you pen testing on?

Serena: 9:31

So I do work at a company, so we are contractors essentially for the company that we're pen testing. So a lot of people need to get pen tests for different reasons. Sometimes it's compliance they have to get a pen test for that or they just want to increase their security posture. Whatever it might be. They kind of come to us, we schedule them, they get matched with an engineer. Because I have a network engineering background, I do a lot of internal and external network pen tests and what that is is basically from an external perspective.

Serena: 10:05

I get the customer's name right and then they will give me a list of endpoints, so a scope right, and these are the endpoints that I can attack from an outsider perspective, starting with nothing From an internal perspective. There's a couple different ways you can do it. Typically, what's most common is we have what's called an implant. They install it in you know, probably their one of their servers. It's just kind of like a virtual machine. It's just an image that we give them and then they just drop me in on their network and I go from that starting point. I don't have any credentials or anything like that, it's just that I'm in their network now and I'm going to see everything that I can possibly see and poke everything I can possibly poke and try to start exploiting from there.

Chris: 10:53

Okay, I'm curious. So it's specifically with pen testing related to networking. If I'm the customer, if I'm this organization and I want to hire a network pen tester, like this is going to be a dumb question. But there are like other tiers of how, like aggressive you're going to be, like, like, like I want you to like attack this kind of stuff versus you know, like, are you ever given to the point where you need to test access layer, like you're actually physically going into an organization, like maybe using someone else's badge or something like that?

Serena: 11:22

I'm I'm super clueless here.

Chris: 11:24

So I just want to see how it works.

Serena: 11:25

So from the kind of like level. So a pen test versus like a red team. A pen test is you're going to have a shorter period of time and it's going to be noisy. You know your customer's most likely going to get alerts. You're not trying to release stealth or you just want to get as much in as you can within that time frame that you're allotted. Versus like a red team, you'll have a lot more time but you want to be stealthy because they are testing their defense as well.

Serena: 11:57

You know where it's like oh, I'm going to, you know, kick this person out of the network.

Serena: 12:02

If I see it, we're going to report it and, you know, possibly treat it like an incident or something like that. So that will take a lot longer because sometimes with that you're going to be writing more tailored exploits for that environment and it takes longer versus like on a pen test. I don't really have a lot of time to write things from scratch, like specific types of code, so I use a lot of open source tooling to do that. Like specific types of code, so I use a lot of like open source tooling to do that, and then you just again try and clear as much as you can in that environment. And then we have something called like an assumed compromise, where it's basically like an employee is a malicious right. So it's like we're gonna give you something like a accounting domain account right. You'll have like the same permissions as someone in accounting would have. Like now try and see what you can do from that point of view from like an assumed compromise.

Serena: 12:56

I like internal pen tests because I kind of like not starting with credentials, because it's fun once I get them and see what I can do with those and, you know, try and escalate my privileges from there. And you know, each one of these kind of has their pitfalls and yeah, so there is definitely tiers and sometimes customers will say, hey, like we're really specifically interested in you testing, like maybe a certain subnet or you know, a certain group of endpoints, if they are trying to test out like a new system that they're implementing and all that.

Tim: 13:31

So yeah, so do you? I mean from a. So I understand, like as a pen tester, you don't have a lot of discovery time, right, like you're, you've, like, you're like get in, get out. There's not like versus red team, which is really about recon and discovery and finding exploits over time, right, so you just kind of get in, see as far as you can get. What is it as far as you can look like? Can you log onto a server and do like a CTF thing, like drop something in the server that says like hey, I have access to the server now. So like to kind of prove that like hey, so like to kind of prove that like hey, I penetrated, like what is it? Because I assume that at the end of this thing you've got to provide some kind of a scorecard or report or something for what that looks like. So yeah, talk a little bit about that if you would please.

Serena: 14:15

Sure, yeah. So we do give a report, like, if you're doing an internal, external report, it'll probably be like over 100 pages, depending on how many endpoints you have. Some customers are so large that we test them every quarter, and every quarter they're giving us a subset of IP addresses, a subset of endpoints, because we literally just cannot test them all at once. It's just too big of a project, right? And so we do give a report. I, we take a lot of screenshots, basically just so many screenshots.

Serena: 14:48

Um, and from a network engineering perspective, a lot of times how I end up getting credentials is by exploiting just on insecure networking protocols and not even necessarily needing to find a specific CVE in a Windows 2008 server, although that's possible. You sometimes are going to be able to do that more so on an internal than an external, An external. These days it's pretty rare that you will actually be able to pivot into an internal environment, just because things are really locked down and typically most of the time, as we see these days when it comes to ransomware companies or companies I guess they're kind of ransomware organizations they are using social engineering as a tactic to gain their initial foothold into that environment and unless a customer specifically requests social engineering. That isn't really included in a pen test Got it.

Serena: 15:49

But we rely heavily on automation. So at the beginning of a pen test what I'll do is use a. It's like a software program called Nessus and it's a vulnerability scanner, and that kind of gives me some stuff to comb through right Like. I'll look and see what there is and maybe get an idea of what kind of starting point would be good, and then also try and validate some of those findings, because occasionally you'll get false positives or it'll be like, hey, this specific version is affected by this CVE, but only if it's like behind a load balancer or something, and so sometimes you're not going to actually qualify and meet all of those standards to have that CVE actually be like a real issue.

Chris: 16:32

Yeah, yeah, another, another clueless guy question here. So I think you know, obviously, if I think about something being penetrated by an attacker, they're probably using either some kind of tool that is either maybe open source, but I assume it's illegal in some fashion. Like they're probably not, they're probably going to be using tooling that is not widely adopted because it's it's malicious, right. So in your day to day as a pen tester, what kind of tooling are you using to kind of mimic that behavior, or is that just kind of the rules of the trade there?

Serena: 17:06

Yeah, no, they're using the same stuff we are. I mean, it's just on GitHub, so a lot of stuff that they are using is just available Right. So I was kind of like talking about like, have you heard of Mimikatz?

Chris: 17:20

No.

Serena: 17:20

I don't think.

Tim: 17:21

I know that one.

Serena: 17:22

I'm going to butcher this on the spot here, but basically it is a program this guy wrote. He had reported an issue to Microsoft about being able to gather clear text credentials that were stored in RAM on a computer. And the problem was Microsoft's like well, that's not an issue because you have to have access to that computer to even get these credentials right, so we don't really see that as an issue. So this guy was like, okay, well, that's BS. And so he wrote a program called Mimikatz. He wrote it because he wanted to learn C or like C++ I think it's C. He wanted to learn C and so he was writing it and this was like his first project.

Serena: 18:01

And I'm like wow, because this ended up being used in a lot and lot of exploits and like with ransomware and different things like that, Because basically, once you get access to one computer, you scrape all the credentials that are in memory and then you can maybe sign into another computer, get access to another account and then just kind of keep going from there and that's how people kind of worm their way into the environment and yeah. So I mean that's just on GitHub and since it's come out it's been used by threat actors verifiably many times. And then, on top of that, like we, as pen testers, use it, people will add to the program, Right? So it's open source. People can submit improvements or features that they want, and that is typically how it is with a vast majority of these exploits. And yeah, we just, we all use the same, the same stuff all use the same, the same stuff.

Chris: 19:03

So people. So people are committing code to the tool that is also being used by the attacker for the exact same. Yeah, that's that's, that's, that's fucking crazy. I mean, it makes sense. It makes sense, I get it, but I just didn't know it worked that way.

Serena: 19:12

Yeah, I mean it's kind of like it's.

Serena: 19:14

it's one of those things where it's like I'd rather see what they're working with than be in the dark about it Right, because ultimately, if this code is being passed around between you know different like, let's say, threat actor groups, right, and we don't really have insight into it, it gets a lot harder to defend against it. That's why, like, malware analysis is like a big deal too, because once we get a piece of malware, we can kind of see how it's working. A big deal too, because once we get a piece of malware, we can kind of see how it's working and then hopefully from there, uh try and either fix the issue where they're being exploited on whatever uh system right, so like a lot of times it's obviously microsoft, um, but other than that you know and just see like how we could potentially stop it, like we did or I don't want to say we did, but like malware tech did when it came to want to cry.

Tim: 20:05

So yeah, well, I mean, and that's like the whole detection Once you also know the malware right, then you can build fingerprints for it, signatures, like I mean that's, that's a huge part of it as well, like you said, not just the malware. The malware analysis leads to protection, right, because then you can update all your intrusion prevention systems and all this other stuff. So, yeah, I mean huge, huge business there.

Serena: 20:27

Yeah, I'm a really strong like advocate for threat hunting and detections, especially because it can really make or break an incident.

Serena: 20:37

I think, like a lot of people should be operating from the standpoint of like we are going to get breached, so what do we have in place, what systems and controls do we have in place to kind of limit the impact of that breach? And a lot of times, early detection is going to make a huge, huge difference, and so that's one area that I think a lot of people are I would say like the majority of people are lacking in my experience, because, even as a pen tester, a lot of times, like I said, I'm very noisy and I always tell our customers like, hey, send me any alerts that you get, because I can include that in my report as a positive finding. We want to also highlight areas where the customer is doing well, and detections is one of those areas, and sometimes I don't get any detections. I would say more often than not I don't get any detections, and this is without me using any type of like stealth, uh tactics or or anything just out the open.

Tim: 21:37

Yeah, actually I'm gonna go ahead, go ahead, chris, I was gonna say so you're factoring detection into that.

Chris: 21:43

you know whether or not the customer was able to detect what you were doing, but I'm assuming is triage involved in that at all Like the response to that, or is it really just about detection for at least pen testing?

Serena: 21:55

It's mainly about detection for at least pen testing, typically like if they're using a sock or you know, they'll know we're in there.

Serena: 22:04

So before I do the test, I give them a set of IP addresses that say, hey, like if you do get a detection and it's one of these IP addresses, it's me. But if you are, you know, if you want to just double check or need to confirm with me for like auditing reasons or whatever, like just send me an email I can confirm that that activity was me. Because at the same time like this doesn't happen super often but it happens where you do get dropped into environment and you will see indications of compromise that they had already been compromised or someone had attempted to compromise them. At one point I do remember being on one external where I was exploiting a upload, a file upload vulnerability which I was able to successfully exploit. But once I got into the system I realized that I was not the first person to try and do that and then you from there will probably have to open up internally like an incident on that company side and go through whatever incident processes that they have in place.

Tim: 23:07

What I wanted to ask is, because you mentioned something about, like the detection being part of it. You want to be able to highlight, you know, that the customer cybersecurity team has done some good work. This is there's kind of this could be. I imagine this can be kind of a emotional on the customer side because you know, especially if do you ever worry that like or maybe you don't, uh, that like the, the customer is gonna, you know, essentially be in trouble. You know that like hey, you were able to to. You know, like there's some, there's definitely a human element to it.

Serena: 23:38

Right, like you're yeah, you know, there's a human element to it yeah, I mean, I even had that problem when I was working in tac, like, for example uh, one thing that I had to do a lot working in tac was root cause analysis, so figuring out why a failure or an incident happened. And sometimes it's like why did this server reboot?

Serena: 23:57

and I go into the logs and I can see the username of whoever went in there and rebooted the server and I have to be like hey, it's like you know this username and the logs rebooted that server at this time and so you're kind of like you don't want to do that. Or especially with like social engineering, which I find a lot harder is because you know, when there's like a keyboard and a screen separating someone, it's a lot easier than when you're just kind of like actually lying to somebody and you know, a part of the social engineering is getting them to like you and feel comfortable with you so that they will kind of like let down their wall a little bit, and so that is something that I kind of like internally struggle with a lot, because I'm just like I don't want this person to get in trouble and I feel like I'm explaining their kindness but at the same time, like this is not good.

Tim: 24:45

If it's not you, it'll be somebody worse than you.

Serena: 24:48

And so that is you know. You have to think about it from that perspective where it's like you know, most of the time people aren't going to be losing their jobs from these reports. At least, like I don't know from people that I've interacted with, I don't know anybody that has lost their job. Not saying it doesn't happen, but a lot of times you just want education right Like it's an opportunity for education, just like how people you know click the test, phishing emails Like I've.

Serena: 25:15

I've fallen for one phishing email like the test, and it was when I was working at Cisco and it was one that was like make sure that, like you know, you're adhering to the dress code, like we need we're sending a reminder out. It was like dress code, like we don't have a dress code, and that should have been like my first clue, right, and then it's again. It's it's an educational moment where it's like oh, like now you can see how this can be exploited and hopefully you just learn from that and, you know, just try and do better in the future. And sometimes it's not even necessarily like the person, it's the policies that they have in place.

Serena: 25:52

And that's an area where you, just you improve your policies, you learn from it, and then we try again next year, next quarter, and and see how that goes and continue to adjust those as time goes on.

Chris: 26:04

Honestly, on a scale of one to 10, how much do you think this has improved your ability to lie? Are you a good liar now?

Serena: 26:10

Oh, I've always been a really good liar, so my mom's a cop.

Chris: 26:15

Oh, okay, so you've basically built a career in lying yeah.

Serena: 26:20

Oh yeah, I mean, we started really young and you have to be a good liar because she will call you on that.

Serena: 26:27

So no, it is something that I think I can do pretty easily. I don't want to brag or anything, but actually I feel like as I get older, I get worse at it somehow I'm just like, oh, they're worse at it somehow. Like I'm just like I was kind of like, oh, they're gonna, they're gonna get me, which is so funny, cause, like when I was younger, a teenager, I was like calling the cable company pretending to be my mom, or like calling the internet company pretending to be her, because she didn't want to do it, and she's like you call them and fix it, and so I have to be there. Like I'm like hi, I'm Heather Depente, yes, like I'm 38 and I'm like 17, you know, so, um, and for whatever reason, when I'm pretending to be her, I I'm fine, but then I try to pretend to be someone else and I'm like, oh, they're going to know, they're going to know, um, but yeah, so so if you've ever, if you've ever, been scammed in your life by Serena's mother, it was probably her instead of instead of her.

Tim: 27:20

Yeah, just kidding just yeah, um, earlier you talked about exploiting network protocols to gain credentials and I, I, I don't know, can you, I I'm just racking my brain thinking of like, which network protocols could you, you know, could you exploit to actually get like access? And are they like? Are we talking like like Talnet, like where you can like find the like? I need to know, because I'm just like scratching my head here.

Serena: 27:49

Oftentimes you're going to be using a lot of relays and spoofing, right? So there's protocols like LLMNR and MDNS that you can spoof and get credentials to, or you're going to be doing like a man in the middle attack, right so all of the protocols that we use in networking. They were defined a long, long time ago right.

Serena: 28:13

Where security wasn't necessarily a huge concern at that point, because it's hard to envision at that time what the internet would eventually turn out to be. I mean, I was talking about this on another podcast where the government was anti-encryption. They didn't want encryption on the internet, and it's like the internet would not work today as it does.

Serena: 28:36

If there's no encryption, you wouldn't be able to log into your bank account on your phone or the internet because your password would be sent clear text, all the communications that you're sending would be sent clear text and anybody in between where you're sending that and who your recipient is. They can just go through and use a tool like Wireshark to go through the data and packets and view TCP streams where they can kind of piece all this information back together. So it was a long time ago, right, and a lot of these are still very prevalent in especially a lot of internal environments, because people have been focusing on external for so long.

Serena: 29:19

It's like oh we got that, you know, real tight, but the internal is usually still kind of like a mess, and so people are really kind of focusing on that area now, which is beneficial. But yeah, you'll be using like LLMNR, you'll use MDNS, you will pretend to be like, okay, ipv6, for instance, you know DHCP, right when you're like, oh, I got to request an IP address. Well, in Microsoft computers, windows it favors IPv6. But a lot of people in their environments do not have IPv6 configured, they do not have DNS for IPv6 or anything like that. And so if I pretend to be an IPv6 DNS server right in an environment where they don't have one configured and I can send them you know information gateways, dns server information and have them send information through me, I can basically gather that data in like a man in the middle of the attack and pull credentials from that way. Smb file share, any types of logging in, there's some active directory ones, but you have a lot of options.

Tim: 30:31

Yeah, so I'm following. So of course, windows by default has IPv6. The IPv6 stack is enabled, whether or not you've enabled it, and with the way IPv6 works, of course you can send router advertisement and then essentially become no, that's good. I've heard of a lot of IPv6 attacks like that but, yeah, a lot of people, like you said, a lot of people don't know it exists or they just leave the defaults. I think defaults are like the biggest security hole in anybody's environment.

Serena: 31:03

Yeah, I definitely agree with that, especially too, because, like Microsoft, we see a lot of permissive default settings. Even when it comes to, like, their cloud Azure environment, there's a lot of very permissive settings. But this is also. They're kind of in the middle of this where it's like well, we want this to be easy to use and don't want to add a lot of friction, because if we add friction, then the customers are not going to like that Right, and so they're going to go with someone else. That might be easier, and I don't. I'm just like riffing off my own, kind of like trying to put myself in their shoes, and so you're kind of really in this difficult spot where the more you restrict, the more difficult it is for a customer, and because it's now more difficult for hackers, though, too right, it's like having a really strong password is fantastic, but it's going to be a pain when you need to type it on a TV remote. You do it you do it.

Tim: 32:03

Yeah, it is a pain in the ass. That is, that is a huge pain in the ass. My kids are always like, oh, I accidentally logged out of uh, netflix or whatever, and I'm like no, that's like a 30 minute ordeal.

Serena: 32:09

If they don't have like the oh, log in on your phone, you know the qr code is such a such a lifesaver on that one.

Chris: 32:15

The qr code login, yeah, 100 um, so know, we talk about this concept of your perimeter, right, and that's obviously very critical when it comes to pen testing. So you know, we've talked a while on this podcast and we still haven't even talked about cloud, which is kind of what we center on. So I want to kind of steer it to cloud a little bit, because you know cloud, you know we just had an episode about zero trust and you know this concept of the kind of ever evolving perimeter and I think cloud kind of exacerbates that, right, because there's such a public presence a lot of things living on public IPs directly accessible on the on the CSP networks.

Chris: 32:54

So whenever you're working with specifically cloud environments, how does how does pen testing change for?

Serena: 33:00

you specifically cloud environments? How does pen testing change for you? It really depends. I feel like from an external perspective it doesn't change that much. I mean, there are definitely more open source tools that I can use to have to basically kind of get additional information. A lot of times with cloud, you are looking for like misconfigurations, of course, like the one example that I always think of first, which is the open s3 buckets, which was like a problem when people started using s3 buckets, um, because they were like, oh, we didn't really realize this was public right and so that's coming back it, yeah

Serena: 33:38

yes, yeah, exactly, and so that's kind of you're looking for these uh little loopholes or these misconfigurations, um, and you are gonna try and basically exploit them that way. I mean, ultimately in the day, like it's still the same systems. Yeah, it's owned by somebody else. It does make it a little bit more complicated because, from like an internal perspective, things get a little hairy right. But, yeah, we do password sprays. That's like a big one on external. So if you're using like Office 365, you just are doing password sprays like you normally would, if it's on-prem or not, and all that.

Serena: 34:19

So it does change. There are some more in-depth things that you can learn, so we do have. So I work at Black Hills and we have a training arm called Anti-Siphon and we have some really great cloud pen testers that work at our company. One specifically, his name's Beau Bullock and he has a cloud penetration testing training which I've taken and it's fantastic and I need to take it again because he's constantly changing it and updating it and there's new tools coming out and things like that. So I'm not an expert in the cloud space yet, but I am learning right.

Chris: 34:55

I mean. But like you said, it's more or less it's infrastructure at the end of the day, right? So the same common exploits you can use on-prem are applicable there.

Serena: 35:04

There might be some slight tweaks here and there with like service offerings, like you said, like an like an s3 bucket or maybe like a pass service or something like that, but the infrastructure, which is what most of the cloud um customers are using so yeah, it works on the same capacity, right yeah yeah, exactly, and I have a lot of people that ask you know, from a network engineering perspective, like how hard is it to pivot into cloud and if you know the fundamentals of networking and they never change they never change, it's all the same. I I took my aws certification. I think I studied for like a week. I took the aws um not the practitioner, like the associate yeah, and it was just learning whatever aws word we're putting on like a load balancer or dns or you know, like a vm and so I'm just like okay, I just gotta learn the aws language for this.

Serena: 35:55

of course, there's um some types of configurations, especially when it comes to like there are other options there. And don't get me started with AWS billing and all that, because that's a whole different piece.

Chris: 36:09

You don't work in FinOps. That's probably for a reason.

Serena: 36:12

Yeah, and so I think that's why I really harp on learning the fundamentals the most, because the fundamentals are going to carry you. Because, like, while technology has changed so rapidly and so much within the last couple decades, the protocols have largely remained the same. Yeah, like it takes forever for those types of standardized protocols to change, because you have to get the whole world on board.

Chris: 36:37

Oh, yeah, yeah For that to happen it's. It's a slow process, I think, not knowing the fundamentals is the quickest way to show your ass in any single. Oh yeah, that you ever take in your entire life as well.

Serena: 36:47

Right, Like yeah.

Chris: 36:48

Like you could probably drill me about you know some nuanced Cisco proprietary protocol, but like if you can't explain TCP, like you're out the door, you know.

Serena: 36:57

Yeah exactly.

Serena: 36:59

I always joke. There's one video that I still to this day. I talk about it all the time because I think it's so funny. But there's a video that I posted. It's like can hackers find your location by your IP address? Like find your home address by your ip address? Like find your home address by your ip address. And this was like a very unpopular uh video for like the between 15 and 19 year old boy demographic who are like gamers, right, and they are like this is like yes, they can, and all this stuff. And I would always link, like the rfc for the internet protocol. I'm like can you show me where in this rfc it talks about location tracking?

Serena: 37:34

right right and they're like I can't and I was like I know, I know, because it's it's a basic right. So you hear these things and you're like, oh, how like location and how does that work? And it's like, oh, that's like a whole separate thing, that's completely different than the protocol and it's, most of the time, not very accurate. And, yeah, I think the fundamentals really trips people up.

Tim: 37:59

Yeah, I think. Yeah, I mean, obviously the fundamentals are the without the thing is. Without the fundamentals, you're screwed right. Like you can, you can parrot your way through terminology, you can, you know, whatever you might be able to force your way through an interview or something. But yeah, I mean, at the end of the day, if you can't, if you don't understand the fundamentals when it comes time to do the thing, you're just not going to be able to do the thing Something.

Tim: 38:22

So something we talk about a lot on the podcast and also where we work, is this idea of the cloud perimeter basically being as close as the workloads and also there's a lack of visibility within the clouds not just not AWS, not Azure, like they all have this problem, a visibility problem. So I don't know, from a visibility perspective, as part of your pen testing that you're doing, when you're thinking about cloud workloads or cloud services or whatever you're trying to exploit, Is visibility a problem for you, or does the customer kind of like, hey, here's what our cloud environment looks like, or do you just have to kind of figure that out yourself? You know, based on that inner entry point?

Serena: 39:01

Yeah. So the majority of the time the customer is going to give me a scope on a red team probably not so much they will say, hey, like figure it out. I've also had customers that have said, hey, the IT team has had a lot of turnover over the years and we're not even really sure, quite like what's out there of us, and so like, can you do some reconnaissance work and do some asset discovery for us? And then, after I kind of do some asset discovery a lot of times heavily relying on DNS and other things like that I will present them like hey, here's a list of assets that I have found that weren't in the original scope. Do you want to add them to the test? And sometimes they'll say yes. Sometimes there's especially when you're working with compliance sometimes they don't want to give you everything that they have because they're only going to give you what they legally are required to give you.

Serena: 39:53

And so that's a little bit of my gripe because it's like, well, from an attacker's perspective, like they're not going to care what your scope is Right, and so that can definitely be a problem where it's like maybe not really giving you the full picture and that kind of adds to another dynamic of pen testing versus like network engineering is pen testing. It's like every pen test you get on you're going to be like some people they don't want you to find anything right, they don't want you to find anything at all and they'll fight you on anything that you do find. And they, you know they don't want you to find anything. Sometimes it's like, especially with compliance, or they're trying to do like a due diligence before they get bought out.

Serena: 40:34

They're like, oh, we need to present this pen test who we're getting bought out by, and then if there's negative things on it, then that deal might be on rocky ground Right might fall through or something super stoked, like the security teams, who's like, yeah, we've been trying to get these changes forever and so now we're going to get a pen test so that we can take that pen test back to these teams and be like, see, like we told you, this is a problem and now we need to get it fixed. And they kind of have that additional leverage. And so you have some people that are excited. You have some people who are not excited at all and there's some people it's like just let's get this over with.

Serena: 41:13

So it's kind of luck of the draw, of what you're going to get.

Chris: 41:15

Yeah, I assume that, like with pen testing, it's like a known thing, like the organization as a whole, like you said, is notified. You're talking with those teams saying, hey, if you get these alerts, these are my IPs, you know, be aware of this is going to happen because you don't want to cause, I guess, too much of a ruckus, right, because you're just testing. But, like red teaming, is that a thing where it's like you want to fly under the radar, you want to actually break in and maybe not cause harm but, you know, kind of showcase the holes in the fabric, right?

Serena: 41:46

Correct? Yeah, I mean our goal is to never really cause any disruption in service, so I don't do any kind of like denial of service exploits or anything like that. That's not cool for the customer or for me and it's kind of pointless because it's like, yeah, like we know right. Another thing like I don't use zero day exploits that aren't like reported in pen tests because it's like, okay, well, if you're using a zero day exploit on the external.

Chris: 42:11

How is the customer supposed to prepare for that right? You can't expect them to be yeah right.

Serena: 42:15

Yeah, and so that's kind of where more of like those internals come in and like detections are where it's going to help you a little bit. But yeah, so it really depends. Like bread team, you might have one point of contact, maybe one. Two people know what's going on and the rest of the people don't know what's going on, so that they can evaluate how their teams respond to a active threat, or you know something like that, and so pen test, though it's noisy and I'm just like I'm here, Hello.

Tim: 42:46

Yeah, I was. I worked at a company many years ago now that they were, they were having I don't know if it was a pen test or a red team, or it was a pen test that they just kept quiet to, you know, simulate or whatever, but I was on the network team, obviously, and you know the security team was asking us questions, blah, blah, blah. Anyway, we, they didn't tell the sysadmins either, and so the sysadmins, they went and found on the server that there's essentially almost like CTF markers. Right, you know, they would drop something in a folder that says, basically, this server has been compromised. You know we could have done whatever to your server, essentially like one of those things, by the company they paid for the pen testing. I assume it's like that, right, like it's more, like you know, as part of your or do you not do that at all? Do you not leave any token? Do you not have any? Is it all based on the report? You know, I don't know.

Serena: 43:36

Yeah, it's typically all based on the report screenshot so, like you know, if I can get access to, maybe like my point of contacts email inbox and just take a nice little screenshot of that in the report. Right, check out their emails, you know, whatever, and so that does happen pretty frequently. But we try not to leave any kind of artifacts behind, and if there is a way that we could not clean up the artifacts, we will have a section in the report that basically says come clean it up.

Serena: 44:09

Yeah, hey, come clean this up, especially in situations like on externals, where I, you know, figure out how to create an account, which kind of happens sometimes. It kind of happens frequently. I would say it's pretty common where I might find an application that I can create an account on.

Serena: 44:26

And the problem with creating an account is that you know you have vulnerabilities that are non-authenticated vulnerabilities, and then you have vulnerabilities that are authenticated, and so there's typically a lot more vulnerabilities that are authenticated, and so once I can create an account, it's like, hey, now I'm authenticated.

Tim: 44:45

And I just opened up a whole new, you know possibility.

Serena: 44:48

Factors yeah, and so you know I try and always say hey, like if I can't delete that account, like make sure you go in there and you know clean this up and all that.

Chris: 44:58

Yeah, I know we're coming up here at the top of the hour, but I just have one more question I want to squeeze in, just because we did recently have an episode specifically focused on zero trust and zero trust in the cloud. And I will say Tim and I have kind of been riffing on this for a while that like we always see these reports that say like, oh you know, 80% of companies or whatever are adopting zero trust networks, and we always call bullshit on it because I've never seen a full, actual implementation of zero trust. And I'm just curious how much that overlaps into your line of work. Just because you mentioned, you know, this concept of you know, I think a fundamental piece of zero trust is assuming breach pretty much all the time, and you want to limit, you know, limit that lateral movement once someone is inside Right and once there's been a breach. So how, how much are you seeing alignment with zero trust kind of in your day to day, or does it really come into your purview too much?

Serena: 45:57

I don't, I guess from my perspective I don't really ask what their policies are when it comes to that stuff. I just do what I can Right. So there's sometimes I'll get access. For example, once I don't know if you're familiar with like a software program called Jenkins. It's like kind of like a software program called jenkins.

Serena: 46:13

it's like kind of like a code repository type thing, um, but it's like there's a lot of exploits for jenkins out there, like a lot of exploits for jenkins, and so sometimes, like I remember, I, you know, was able to capture credentials through relays. I was able to sign, sign into Jenkins, and then the account that I had access to did not really have that many permissions, but then through Jenkins I was able to dump logs, log files, and through those log files I was able to kind of just like I'll search like a service like SV underscore Sometimes they have like service domain accounts and I will grab a service account that has credentials. And then I'll be like, oh, I'm going to use a service account and the service account has way more permissions. So you're not even like thinking just employee accounts, right, like I'm, I'm using your service account to log in and pivot from there.

Serena: 47:11

So you know, things like that happen. Sometimes you really don't know, like, what you're going to get in a relay, what kind of credentials you're going to end up with. And my thing is, I'm just going to try and escalate from there because at the end of the day, I want to get domain admin, because that's.

Tim: 47:27

Yep, yeah, that kind of. That's the keys of the kingdom at that point.

Serena: 47:31

Yeah, it's a wrap after that, and so you know it really depends. I don't really ask a lot about their posture. I'll ask things like you know before. Like you know are you using any type of deception technology? You know any honeypots? Because sometimes that can like really become a time suck, if you don't know.

Tim: 47:57

And with a pen test with a red team.

Serena: 47:58

It's like, yeah, waste their time, but on a pen says like you only have five days, so we want to get our money's worth, right, so don't mess with the honey pots and things like that, right, um, and so I, I would say that from an internal perspective, um, I really I don't really see a lot of of complications with zero at this point I. I'm still impressed when I see that there's actual like segmentation on the network.

Tim: 48:17

Right, right, let alone zero trust right so.

Serena: 48:21

I think maybe for more well-established companies that have been really really on their security game. Maybe they're in a different space and I just haven't really run into them yet.

Tim: 48:35

I think this is unintentionally interesting because, like, one of the biggest ways that zero trust works is by identity. Right, like identity is a big driver of how people know what I have access to. Zero trust stuff is going to be based on accounts, and what I'm hearing is basically like zero trust, isn't so, therefore, the Achilles heel of zero trust is, you know, is your account, is your identity right Is your account.

Tim: 48:59

So I think what you're saying, serena, is a big you know. You know it's essentially by proxy gaining access to service accounts and things like this, you know, is actually almost like an exploit around zero trust, all these amazing zero trust principles that they're trying to put in place.

Serena: 49:18

Yeah, and don't get me wrong, I would say like it's still helpful, right. So sometimes we see with threat actors they usually have especially like these ransomware groups they'll have a another group do the initial access and what we see a lot of times and these are younger people that are really just kind of like doing the social engineering aspect to get like an initial foothold and then they'll kind of reach out to ransomware group and the ransomware group will offer their services and it's a mutually beneficial agreement that they come to. And so it is helpful, right. Like if I do get access to an account or we're on a Zoom compromise and you're like why is this guy in accounting opening PowerShell Like red flag, right, Red flag? Because that probably shouldn't be happening for someone working in accounting, like these things. That's why I say like detection is because the sooner you can get them kicked out, the better, the sooner you can isolate them the better.

Serena: 50:16

And you know, sometimes it depends how much skill this person has. When they get an initial foothold, they're not able to like get anything out. So sometimes, aside from ransomware, they want to kind of like blackmail you and they'll be like, hey, you know, or extort. We're like we got all of these customer data files right. But there's things that you can put in place in your environment that will limit the type of data and the amount of data.

Tim: 50:49

With DLP.

Serena: 50:50

Yeah, exfiltrate out of that environment, and so you really have to have a really well rounded security posture. And that is a marathon, not a sprint, right.

Chris: 51:01

Absolutely.

Serena: 51:02

Yeah.

Chris: 51:03

No, I think you make a great point. There is that, like you, when you go into these environments, you shouldn't really have to care right, the attacker is not going to care right About what kind of security framework they're adopting. If you, if the results are the results, right, if you get in, you got in. Doesn't matter if they say they're you know, zero trust to the gills, right.

Serena: 51:20

Right, yeah, especially too, because I mean, unless there's something like, hey, this could impact patient care, so don't do this, right, like we want to know that kind of stuff. And you know we don't want to topple over someone's environment, Not good for us, Not good for them. And yeah, I just I kind of really go in with limited information. I only ask a few questions. They ask me questions and then we kind of go about it and I try and limit the amount that I know about an environment going into it.

Serena: 51:52

So everyone's going to be different and sometimes it's like great and sometimes it's not great.

Chris: 52:01

Nice, all right, well, yeah, with that, I think, we will start to wrap it up. I think this has been, this has been, a phenomenal conversation.

Tim: 52:08

I think I've.

Chris: 52:09

I've probably learned more than anyone out there listening, maybe, but yeah, this has been good. So, serena, thanks for coming on again, and real quick. I wanted to give you an opportunity to plug your podcast. Where can people find you online? Anything else you want to plug?

Serena: 52:24

Yeah, you can find me online at SheNetworks, on X, twitter, whatever it is.

Chris: 52:30

We call it Twitter here, that's Twitter.

Serena: 52:33

Twitter, youtube it is. We call it Twitter here. Twitter, youtube, tiktok, and you can also find me on my podcast at Breaking the Internet with me. She networks in my co-hosts, ending with Allie. She's kind of a Twitch streamer in the security dev space. So, yeah, you can find me there and we only have, I think, like three or four episodes out of our podcast, but we have way more in the pipeline. So we really just talk a lot about, like what's happening in the tech world. It's not all security focused, although we do talk about that, but it's kind of more just like hey, like what's going on with this, and we kind of just dive into topics that we find interesting. So if you need a chill listen, check us out.

Chris: 53:15

Sweet, awesome. Thanks for that, we'll put all this stuff into the show notes, links to where you can find Serena and everything. So with that we'll go ahead and wrap it up for today. So if you enjoyed this, please like subscribe. Do all the things we ask you to every single week. If you haven't done it yet, why the fuck haven't you done it yet? Do it now, and with that we'll take it away and we'll talk to you next week. Thank you.

Tim: 53:37

Bye, see you guys.

Chris: 53:38

Bye.

Tim: 53:41

Hi everyone. It's Tim and this has been the Cables to Clouds podcast. Thanks for tuning in today. If you enjoyed our show, please subscribe to us in your favorite podcast catcher, as well as subscribe and turn on notifications for our YouTube channel to be notified of all our new episodes. Follow us on socials at Cables2Clouds. You can also visit our website for all the show notes at Cables2Cloudscom. Thanks again for listening and see you next time.