Explore offensive security with expert Phillip Wylie as he shares insights and strategies to stay ahead of evolving threats
Guest: Phillip Wylie, Security Solutions Specialist at CYE [@CyesecLtd]
On Twitter | https://twitter.com/PhillipWylie
On LinkedIn | https://www.linkedin.com/in/phillipwylie/
On YouTube | https://www.youtube.com/@PhillipWylie
Host: Josh Mason
On ITSPmagazine 👉 https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/joshua-mason
______________________
Episode Sponsors
Are you interested in sponsoring an ITSPmagazine Channel?
👉 https://www.itspmagazine.com/sponsor-the-itspmagazine-podcast-network
______________________
Episode Introduction
Explore offensive security with expert Phillip Wylie as he shares insights and strategies to stay ahead of evolving threats
Join host Josh Mason in an engaging conversation with industry expert Phillip Wylie as they delve into the fascinating world of offensive security. Discover the evolution of pen testing and cybersecurity, the significance of threat modeling, and the need for education and awareness. Gain valuable insights, real-world examples, and strategies to stay ahead of evolving threats in today's digital landscape. Whether you're a seasoned professional or just starting, let Phillip Wylie's expertise guide you through the dynamic realm of offensive security.
______________________
Resources
TryHackMe: https://tryhackme.com/
Hack The Box: https://www.hackthebox.com/
______________________
For more podcast stories from Loops and Lifecycles Podcast with Josh Mason, visit: https://www.itspmagazine.com/loops-and-lifecycles-podcast
Watch the webcast version on-demand on YouTube: (coming soon)
Josh Mason: [00:00:00] Welcome to Loops and Lifecycles. This is Josh Mason. Today, I've got with me a good friend and mentor, Phillip Wiley, who's known for his speaking, his book, and just for being a overall great guy in the network and web app pen testing space nowadays, but with quite a varied background, Phillip if you could say hi to everyone.
Phillip Wylie: Yeah, thanks for having me on the show and hello to everyone. It's a honor to be on your new podcast.
Josh Mason: Truth be told, it's an honor for me. I've been listening to your podcast for a while and done a lot from our the mentorship that you've given me, sir. The reason I was thinking other than I just love talking to you reason I was thinking of having you on the podcast here is I'm focusing on the DevOps life cycle and a little [00:01:00] bit of how that.
Actually fits into other parts of life and society. If you could, how do you see Pen testing, web app pen testing. I think of mostly with the DevOps life cycle.
Phillip Wylie: Sure. One of the things I've done in the past is in my consulting days, I did a secure software development lifecycle review for a company and it's things have evolved to the cloud with the DevOps.
Type of method people are using these days, but a lot of the things are similar, but one of the things I think that kind of gets overlooked sometimes with getting in the dev ops and application is I do think that this may not be the main topic of this conversation, but I think one of the things we need to make sure we don't overlook is testing the infrastructure because you can have a very Secure application, but if the foundation is not secure, someone can get in.
[00:02:00] That's like having a really secure front door, but maybe the garage door is not secure. You totally forget about that. So you need to make sure that the whole infrastructure is secure. And I think one of the things that you have to do. Is making sure that penetration testing is included in your life cycle, as well as some vulnerability scanning built in previously, people were just doing testing as an afterthought.
But now, since things have evolved, people are testing through the life cycle and then performing pen tests, like a major changes to an application. So I think it's really good. To have that kind of built into your process. And I've experienced that with a company where I was leading the red team and we outsourced our web app pen testing.
And we had some app sec folks in house, but one of the things that we really learned lesson wise there is when you really have that built into your culture, that security [00:03:00] is part of the development life cycle, then usually people that are involved in the development piece and the business units will usually.
Play well and make sure that those steps are being included in cultures that you don't have that a lot of times it's overlooked. It's really hard to make that a habit and get people to comply.
Josh Mason: Man. Yeah. You hit on all those same thoughts that I was having that if you don't have your internals, if you've got those other pieces of the pie that. Aren't fit together correctly, then you're going to end up with problems not just in your app, but overall, and then tying that directly to the culture of the company and everyone having that security mindset while they're developing is so crucial.
So crucial. Do you find is. That's something you've seen a lot. Is [00:04:00] it a struggle? Do you think it's something that as an industry folks are moving towards?
Phillip Wylie: I think people are moving towards it. I think some cases it's still a struggle. I know in some organizations that I've had experience with that, maybe you're doing pen testing.
In as a requirement for PCI and some cases, the business units or some of the people on development side or project managers really want to get this done quick as possible. And sometimes they don't really look at the overall picture. We need to make sure it's secure. So we really need to get buy in.
I think really education goes a long ways. Just showing them Thank you. Help them understand the process and let them know the repercussions. If you don't make sure you're not doing these pen tests, you're not securing things properly. What happens if the bad guy gets in? And that's the main reason we're doing the pen testing.
We're wanting to see what a threat actor could possibly do and trying to mitigate against those.
Josh Mason: Yeah, exactly. Do you find [00:05:00] that you have to do some of that translation when you're working with? The client with the customer in your pen tests, do you try to do that up front or during the process or in the report?
How do you find it's best to try to work that in?
Phillip Wylie: Sure. I'd say just from a pen test to pen test basis, or even with an organization, if you're building out a program is to have the end user or the customer involved from the beginning. Let them know that you're on the same team, that you're trying to help each other out because some cases developers feel like that the pen tester is trying to make them look bad.
And that's not really the case where we're working together. So you want to set those expectations, starting out, letting them know you're a team and communicate things in an understandable language and not use all the jargon try to put yourself in their shoes. And one good way to, to look at is you look at sales and business.[00:06:00]
Us as techies, we hear some of these these terms the first time it's like another language and same thing with if you're dealing with developers, even sometimes. The business groups are just some of the business analysts that are involved in some of these softwares. We need to make sure that we're communicating with them in a way they can understand.
And then that's going to be even more critical when you're dealing with people that are less technical, make sure you're explain that in terms they can understand, maybe even do some education. Sessions where you discuss pen testing, different types of assessments that are performed, help them understand it.
I was in an organization once where people even in security didn't know the difference between a vulnerability scan, a pen test, a red team operation. And so they really know the difference, even a vulnerability scan. So they didn't know the difference between these items. And once it was [00:07:00] explained and provide them some documentation, they understood that it was easier to communicate.
Josh Mason: Oh, yeah. Oh, we had someone reach out to us recently in a similar spot. They said, we need a red team assessment and what they were looking for was a pen test, but initially it was okay. We want to make the RFP or the statement of work fit what you're expecting. And in those details that we.
We had to do a little bit of that. This is what red teaming is. This is what pen testing is like, how deep do you want us to go? And how do you want it? What is the scope? Are we going after the whole organization? Do you want us to play like an actor? I imagine you, you run in that often now.
Phillip Wylie: Yeah, one of the things too, that's one of my big pet peeves in the industry is the generalization of calling it red team and calling a pen test.
It's just because over the years you got the blue team, which is the defenders, but the same, even with the defenders, they're not all doing the same [00:08:00] thing. It's different. And so when I refer to. A generalized term for pen testing, red teaming. I like to use it offensive security because that easily fits in pen testing and red teaming and all the different various types of activities that fall under offensive security.
But yeah, there's a lot of confusion in the industry because I, when I worked at the company's red team lead, he really, the, one of my directors, he needed, we needed a application pen test done on some SAP apps. And it needed to be a pen test, but he requested like a red team operation and you're not going to red team an SAP app because you're going to you in pen testing, you do use some adversary type techniques, but you're just really trying to uncover all the vulnerabilities.
But yeah, just that generalization or just. The misconception of red teaming being the same thing. And that's why anytime I talk to someone, and [00:09:00] if you're talking to a consulting company the guys you work for, I know they know this well enough and they've experienced that enough, but you make sure you communicate that with the customer to let them know, are you wanting adversary emulation or a penetration test?
Do you want to find all the vulnerabilities or you're trying to emulate a threat actor and. There's really value to both of those. Really, a mature organization is ready for red team operations, someone that's not very mature in their vulnerability management program, and their pen testing is not really quite ready for a red team yet.
Red teaming. So pen testing for the listeners. Pen testing. You're trying to find all the vulnerabilities that are exploitable. Try to exploit them. See what you can do post exploitation. What else you can do once you gain that access. Whereas with a red team operation, you're emulating a threat actor.
You're finding maybe one way in, maybe a second way in to maintain access. You're leveraging heavily on social engineering and sometimes some physical security assessments [00:10:00] in that. But with a pen test, you're just mainly focusing on trying to vulnerable to look for the vulnerabilities.
They're both limited in time in a red team operation. And sometimes you've got. A lot more time, but you're just focusing on these certain items and goals within that. And you definitely want to make sure you're doing pen testing once your organization is mature, adding in a red teaming, because maybe everything's really secure.
You've been going through your pen test. You've been remediating things, but if someone is able to get access. To a computer that's logged in as an administrator. It doesn't matter. You can have the best in class endpoint detection and all that. And someone gets ax domain access or whatever you don't have to be that great of a hacker if you can just get access.
So sometimes people overlook
Josh Mason: that. That's a great clarification. Thank you. You're welcome. It has me wondering, do you have something that's your favorite? Do you like doing web apps or [00:11:00] infrastructure? Or are red team engagements your favorite? I know you just had David Moses on your podcast and I totally forgot about that until you mentioned it.
Yeah. They both have separate things that they focus on and that they prefer. I'm curious what
Phillip Wylie: yours is. It's interesting because over the years I really liked the infrastructure pen testing more, but I've gotten in recent years, more interested in the web app pen testing piece. It's just so much, it's so much different from time to time.
Sometimes doing infrastructure pen test that stays pretty similar. I've done some red teaming, some adversary emulation, but really not as much as I would have liked to. So that's an interesting area. And I think for anyone that's looking for those type of roles, see what interests you and it and you don't have to, you're not.
Locked into this one type of thing, the skills are going to help you in other areas. And I see, even if you're an infrastructure pen tester, it behooves you to learn web app pen testing, because a lot of cases you may get into an environment [00:12:00] that you can't get a foothold in, but maybe you can through a web app vulnerability, because a lot of these consoles that manages some of your security products run on like Java servers Apache Tomcat or Red Hat Jboss.
So sometimes you're able to exploit one of those. You get access to you sometimes you can upload a malicious war file, which creates a malicious Java. Application and sometimes you can get command line access, take control of the system doing that. So these are some areas and a lot of the reasons that you need to thoroughly test like infrastructure, because if you're just focusing on an app and you're not focusing on some of these other areas that could be using like these Java servers, you're missing out on some possible vulnerabilities that can be exploited by a threat actor.
Josh Mason: It's very true. Do you find more of the web app ties back to helping during a an internal, if you will, and [00:13:00] infrastructure or the other way around? I've seen some of the web pen tests that our folks have been doing. They end up pivoting into a cloud pen test, or if we also get in the dev environment, then all of a sudden we're looking at the servers and we find more like you, you're pointing out more than just.
The app that they're showing, maybe they're running some other things on there so that if someone got access to the dev environment, now they can know more about the internal. Is it, have you seen a lot of that? Like where maybe a web turns more into a cloud or turns more into an infrastructure than you were expecting?
Phillip Wylie: Sure. Yeah. Yeah. Some cases it does. And that's mainly, I would say mainly from the internal. And that's one of the things that you have to be careful when you're scoping the things and people that are wanting a pen test performed sometimes your scope, you may need to expand a little more because [00:14:00] sometimes some lost opportunities, I was performing a pen test back in 2014.
I found a SQL injection vulnerability. They had XP command shell enabled, which allows you to get command line access to the Microsoft SQL server. I got command line access, but. Due to the scope, I couldn't go past that. So that's some of the reasons sometimes you want to include some infrastructure pentesting too.
If this would have been an infrastructure pentest also, then I could have tried to see what I could go past the server because I was able to dump the password hash and back in 2014, Hashcat was around, but I just really hadn't used it much. But I used John the Ripper and cracked the password hash in 30 seconds.
And it was password all lowercase and the number one. So odds are. If this would have been a larger scope pen test, I possibly, and probably would have got access to other servers in that environment, but the sad thing was in the frustrating thing, they filed a risk acceptance because it was a dev server.[00:15:00]
Yeah
Josh Mason: It's one of those all of a sudden someone realizes, Hey, the dev server could be the backup sets up the firewall wrong. And now you've got that leak everywhere or
Phillip Wylie: yeah. And is it segmented injection? Yeah. It, or is it segmented for the rest of the network? Odds are, I guarantee you there were other servers in that subnet that I possibly could have.
Could have actually end up hacking into one of those and they may have not been dev is, was probably production and dev was probably all on the same subnet. Yeah.
Josh Mason: I wouldn't be terribly surprised. And back in 2014, people weren't in AWS Azure, so they might've been self hosting and that could have been messy.
Yep. Yeah. How have you seen the evolution of pen testing and kind of cybersecurity? Do you [00:16:00] feel like we're maturing in a thoughtful way or is it everyone's as the technology evolves, people are just trying to catch up. What's your take? I know you're an, I'd say you're an industry leader for cybersecurity.
Phillip Wylie: One of the things I'd say is people have caught onto the need and one of the things that's helped the need is compliance pen testing. When people have to do it, they're going to do it. A lot of cases security budgets are so tight. People aren't going to do things they don't have to. And that's a mistake.
So I think it's catching on people realize, but I still think there's some more education that needs to happen in the industry. Because one of the things I see in my opinion, offensive security is probably one of the least understood areas. Of cybersecurity, because you take a lot of these people. You figure there's a lot more jobs on the blue team side than there are the offensive side.
So there's more people with the defensive experience over the offensive experience. So I just think a lot of it requires some education, going back to what we were talking about earlier, [00:17:00] where some people don't know the difference between a red team, red teaming, or a pen test or a vulnerability scan is making sure the education is there.
Things are really getting on the right path. There's a lot of great people out there offering. APSEC training, just like Tanya Janka she hacks purple, she has some really good content out there. So it was getting to be a lot more good stuff on how to defend against it, how to to do a good application security.
So things are maturing and getting better as a whole.
Josh Mason: Nice. Thank you for that perspective. It's always something that I'm wondering about. Like we look at it. No clients, industries, organizations, and how are they maturing as they're starting to get security going across their enterprise? And I can't help, but reflect on how are we as an industry maturing?[00:18:00]
Are we at a CMMI level two or three, just as the security industry? That's what I wonder about. And I know there's you've been very vocal the past few years, educating On how to get in, what all of this means. Do you think that there's more space for that? More
Phillip Wylie: need for that? Yeah, I believe so.
And when you mentioned the difference between like the enterprises evolving versus the industry, I think the industry is still a little bit of head, a little bit ahead. There are some enterprises that are up to date on the latest technologies. They're doing a really good job. Some cases it's. Some companies are limited on budget.
They can't do these things. They can't hire the talent that some of these bigger organizations do. But I think it's improving there, but I think more like the industry is people trying trying to catch up with what's going on, the trends there. [00:19:00] And yeah, that's my thoughts.
That makes sense.
Josh Mason: I can't help, but try to connect things in my mind. It's how I make sense of all of it. And when I think of my background flying how we determined if planes are safe or not, obviously you engineer them, you build them, but then they have to be tested and no kidding, they build some planes and then just start lifting up the wings to see, we know it's supposed to break at this point.
Let's try it out to me. I think of it as QA it's QA testing. It's what we should be doing with AppSec, but I don't know if we think take things to the same severity as we do for safety and is there something similar to that testing where pen testing in the rest of [00:20:00] sorry, I started thinking, how can we.
Kind of take the pen testing approach to other things in life to help find ways that we can improve. Do you find yourself ever wondering like things like that? If there's a hole here, how could that be exploited? And can we make this process better overall? For example I was at an AT& T store earlier getting a SIM card for data and just seeing how things were laid out.
I was like, this is creating issues. Obviously they set things up for one reason or another, but coming in with that different mindset of kind of a pen tester, I know this is working, but what would break it? Do you find yourself ever having that sort of mindset as well? Yeah.
Phillip Wylie: And I think one of the ways that people can address some of this, because you hear a threat modeling and people would do threat models against certain environments they're going to [00:21:00] assess.
And the more complex the environment is or more. Less understood than you, it's really important to do the threat modeling you're doing a web app pentest, people know the different type of threat vector. So a lot of cases, it's not threat model, but I think one area for opportunity is threat modeling and organization as a whole.
Look at the physical locations, how people access data centers, maybe factories R and D departments where this data is being held and just think of threat modeling that. And I think that will be a better way for you to assess the security and learn how to secure things once you figure out how, what affects it.
And some of those are in the environmental items. Like for instance, when I worked for a bank, I sat in one time when a consulting company we outsourced our ATM pen tests. And it was really interesting to do the threat model on that because some of the things environmentally that you would take into consideration.
If the ATM [00:22:00] is within a building with a camera on it the bank lobby, the, just the little section where you can go in and access the ATM, it's usually more, a little more secure because you've got security guards going by, there's traffic from pedestrians passing the location, but you take that same ATM and you put it out at a gas station out in the middle of nowhere.
It's maybe minutes away from police being dispatched to try to apprehend anyone trying to get in that machine compared to in the city with the cameras and all this. So you have to take some of those things in consideration, the environment and the type of attacks what it's connected to same thing when you're looking at an internal environment, an air gapped environment versus something exposed to the Internet.
Taking consideration, the type of threat actors, the environment, the opportunity and. Take all those into consideration when you're designing these things, because a lot of times physical security gets overlooked so much with the social [00:23:00] engineering stuff, people do these phishing campaigns and sometimes they don't do actual social engineering.
A lot of these apps are good. No, not say don't use them, but the little campaigns that you routinely send out the checks to see if people clicks on things really isn't going to tell you what happened and someone clicks on it. What happens if there's malware in that attachment, what are you gonna be able to do from there?
You need to be able to test that. So in those types of cases that you need to be doing some actual phishing campaigns and not just the apps that send out the email to just track the clicks, you need to see. What's going on is someone clicks it, try to put things in place to protect against it.
There's some good software packages for email out there that if you click on something, it's not going to let you go somewhere. It sets their checks, all these URLs. And so it provides a layer of security. So I think just overall, we need to be looking at all those things. Doing a threat model and just testing everything.
And other thing to think about too, is like software QA. So anyone that's [00:24:00] into application security, DevSecOps is also think about software Q and A. You're looking for flaws in the software, what would cause it not to work or whatever, and also apply that to your security.
Josh Mason: Yeah. They all tie together real nicely.
What would break the web app? What would break our physical security, having that same mindset in all different sections and threat modeling through it kind of solutions architecting from the beginning quite crucial. That's exactly what I'm hoping people begin to do more and more often.
A lot of the the recommendations out of some of our pen tests have been, are you guys doing threat modeling? And some developers that I've talked to [00:25:00] weren't even sure what threat modeling would look like for what they're building. And I've talked to some college grads and I'm sure you've talked to plenty as well.
Threat modeling isn't really something that's taught during computer science classes. It's can you build something? Can you follow the rubric? And can you make the the thing on the screen dance the way the professor wants you to, but not necessarily, okay, is it secure? Where are the keys?
Where are the passwords? What are the requirements? And like, how might someone destroy this? I'd love to see some threat modeling thrown into some of those, Curriculums.
Phillip Wylie: Especially when you see they should have them bachelor's degree, especially when you get into things, master level security degrees, definitely should have something like that.
Agreed. We should talk to some
Josh Mason: people. Yeah. Follow up from this. Yeah. And the
Phillip Wylie: same thing of that, what the threat modeling also does, [00:26:00] you'd find the threat vectors, the probability and all this, it also does is it helps you prioritize what needs the most attention. So that kind of, from the threat modeling, you see.
What's more critical to focus on. So if you're limited budget, you need to focus on this here first. Oh, yeah.
Josh Mason: Something I got introduced to along those lines is technical debt. And I always thought of technical debt as you've got people with you've got a windows XP machine, or you've got server 2003, because that's what things were built on and no one's been able to update it.
But in the web app side, some technical debt just being that we pulled code over and it has bugs inherent in it. And as we go through QA testing or as pen testers find things, now you don't only have to add features or streamline the app, all of the normal development CICD type stuff. But you also [00:27:00] have to go back and fix the issues that the pen testers or the QA found.
And just that idea of if you can prevent technical debt by thinking these things through beforehand, by planning a little better, and that includes the threat modeling, then you end up. Getting to your final better product faster.
Phillip Wylie: Yeah. And you brought up a good point too, when you mentioned bringing over this app to another system.
Installing another thing too, with the reason for infrastructure, even when people are doing a web app, pen test, is to do some network vulnerability scanning and some port service scans. Because sometimes when PE people build these apps, maybe it's an upgrade, maybe that they're running like Apache.
Tomcat now before, maybe they're running IIS and it could be just a matter of, okay, they were doing a pilot on these apps and they decided to go this other version. They didn't [00:28:00] remove what you should, if you're not going to use IIS or some other software, you should remove it because it does a lot of cases it may get missed on patches and you're just.
Having unnecessary vulnerabilities there. So in some cases things either get decommissioned or they were piloting a certain version of the app or another app, and they didn't take that out of commission. So sometimes these are some opportunities for a threat actor to come in. You're.
App server that you got the application running on, maybe working great, maybe secure, but some of those other softwares running on there may not be. Yeah.
Josh Mason: We're at time, but man that last one really, it got me thinking of a story. There's things in the air force where. People pitch something and they're like, do you like this?
Should we continue developing it? And they're like, we like that perfectly. Just make us 10, 000 of them. And you're like no, this is, they're like, yeah, here's the [00:29:00] money. Make it happen now. And I can just imagine how many apps there are that had the same thing happen where, Hey we tested the thing.
How's it look boss. And. CEO's okay, we got to get this to market now. Everyone was like okay.
This has been great, Philip. We, I'm definitely going to bug you later so that we can chat some more. Sure. And where can people find you? I know you're at all the things these days.
Phillip Wylie: Yeah, LinkedIn and Twitter. And of course my new podcast, Philip Wiley Show which can be found at philipwileyshow.
com. It's available on YouTube, video, YouTube and Spotify in video format, all the other platforms on audio, even iHeartMedia and Pandora. Excellent.
Josh Mason: And is it also a Philip Wiley show on YouTube?
Phillip Wylie: Yes, yep. [00:30:00] Okay. I got a playlist under my podcast channel, which is just at Philip Wiley. And so under there, there's a playlist, which for the, for podcasts that it's under there.
So perfect.
Josh Mason: Thanks. And if nothing else, I hope to see you next month
Phillip Wylie: in Vegas. Yeah. Thanks. Look forward to seeing has been a while and I look forward to catching up in person. Thanks, Philip.
Josh Mason: Thank you all for listening and join us next time on loops and life cycles.