speaker-0: Welcome back to another MSS edition of Initial Access. ⁓ last time we dug into specific campaigns and ⁓ what managed services actually look like from the inside. We talk about threat actors, ⁓ we talk about vulnerability intelligence. ⁓ today we're staying kind of on the same line, right? We are going deeper into three things that are first frustrating for practitioners right now. One is how fast the threat landscape moved since we last talked. ⁓ Richard and I qu we were just discussing about like how many new patch USA things got published, right?
speaker-1: Two minute, two minutes.
speaker-0: Too many. Yeah. ⁓ we're gonna talk why ⁓ the way most teams consume tech intelligence is broken, right? ⁓ something that it's always in my head is like atomic indicators of compromise. Are they wordless? Kind of, maybe. We will see that. ⁓ finally we will discuss a bit of ⁓ what ⁓ how to not necessarily how to, but what is actually ⁓ what it means to scope your Intel program. So yeah, so you can get something useful from it. So ⁓ I'm Sergio Villegas, ⁓ Senior Managing Managing Analyst analyst. I'm joined today by Richard Brown, Senior Managing Operator, and Kendrick Urbanag Urbanak as senior operator. So welcome guys. How are you?
speaker-1: Good, good. Thanks for having us as always, man.
speaker-0: Yeah, it's great. ⁓ I think time will by really fast. Another month, another MSS episode. ⁓ this is the second episode. I'm I'm excited we didn't got cancelled last time.
speaker-1: We normally get ⁓ the pilot and then a couple episodes, right? Character building. The character building episodes.
speaker-2: Yeah, yeah.
speaker-0: That's a plan. ⁓ some ⁓ quick updates and and shoutouts for the team. ⁓ we are going to have some events ⁓ where many of the foxes ⁓ will be participating. ⁓ so please when when you are seen ⁓ when you are hearing us, if you're hearing us ⁓ the when we release this episode, we will have Patricio Sanchez, he will be speaking at the FIIAC. It's ⁓ conference in Mexico. ⁓ he's gonna bu he's gonna be talking about like zero trust identity data protection. So hope to meet ⁓ you guys in there. It's gonna be a good one. This is gonna be in Mexico. So really good to see this. ⁓ we will also have ⁓ Salvador Rodriguez, he's going to Pownet CR. This is a Costa Rica event. So yeah, we are going more international now, right? Like covering ⁓ other conferences beyond we always cover DEF CON, we always always cover the big ones, but we also cover very ⁓ regional specific events. We we like the community, so we will do that. He will be talking about ⁓ building real world offensive security automations with agents, skills, MCP. So yeah, you know, all of the AI stuff we we like in initial access. ⁓ also for next week we have Samantha Randa. She will be on our Discord. So also ⁓ don't forget to join our Discord or Discord or subreddit. ⁓ she will be leading a couple of ⁓ workshops in there. ⁓ first one will be in English September fifteenth. Second one will be in Spanish September seventeenth. ⁓ she will ⁓ she will do some ⁓ the workshop is about weaponizing co formation. ⁓ yeah, it will be a lot of like AWS offensive skills. It will be great, right? Like I'm I'm really happy to to see us scoring not only the English world but also the Spanish one. ⁓ if you don't know, right, like Beach of Fox has a lot of like team members from other re regions beyond ⁓ the US. So it's cool to see that. ⁓ so yeah, I think that's a great ⁓ yeah talking about like offensive skills, talking about like everything that is bad in the world. This is a great segue to our first story, right? Like what happened between last time we talked, last month, to today, right? ⁓ It's been four or five weeks if I remember correctly. Yeah. So we saw the I was I was patched and actually as this episode is being recorded, there is another patch Tuesday that went live. So we're not talking about today's patch. We're talking about till the previous one in August. So it was a lot, right?
speaker-1: Yeah.
speaker-0: ⁓ it was one of the l largest in history. ⁓ there was over a hund over four hundred CDEs in Microsoft products alone. Hundred eight of them were rated critical. ⁓ this is ⁓ yeah, this is a twelve month average. in the in the twelve month average is around eighteen critical, but this time a hundred eight. It's a lot, right? It's a lot of vulnerabilities. ⁓ we also ⁓ had some very specific ⁓ vulnerabilities ⁓ already exploited in the wild. ⁓ so the CSA key key we listed them. So it it was kind of a really wild wild quest for Agos in terms of like ⁓ vulnerabilities being disclosed. And I know last time we talked about vulnerability intelligence, right? So the real question in here, ⁓ what do we do? Right? Like I have a four hundred vulnerabilities. I can't cover all of them in a single month. And this one we have hundreds more, right? Like How do you manage to triage all of that in a realistic time frame? Right? What does the or how does the workflow of of managing all of that look like when it's at high, right? Like what do you do? Where do you start? ⁓ is there an end to it whenever you're managing Google this? I know. What what are your thoughts, guy?
speaker-2: I think for the most part no, th th it's not manageable to to do four hundred and something CPEs in a in a month. ⁓ you're gonna end up applying pat patches blindly and you're gonna hope it doesn't break anything, and then when it does break something, you roll it back and you go on in patch number four hundred and twenty two and then you hope that one doesn't break anything and then you keep on going and rolling it forward. I mean ⁓ this month is gonna be even worse for for Blue team and patching things, like that's it's not gonna be a whole lot of fun patching a thousand different things. Hopefully, ⁓ they can roll those all into one, but it's not looking great right now.
speaker-1: And and that's even if you understand your infrastructure enough to know if it's gonna break anything downstream. Right. ⁓ I think that's one of the reasons why most places have like a thirty day window between patches for n for non critical things. Don't don't wait thirty days for critical things. But they have that window because they're trying to figure out what's gonna break when they patch this. And I think we are getting a little further away from the days of having that one server that has an uptime of six hundred days, but ⁓ we're not far, you know, we're not that far away from it. So Definitely tough. AI has increased exponentially the amount of C V E's we have to deal with on a daily basis. And I feel bad for internal teams because I like Kendrick was saying, I don't know how you're gonna do it. ⁓ physically understanding your attack surface to know which patch to put in priority of the other one is a job in itself. And if you're doing other things like managing networks, you're gonna be falling behind. Or should I say managing devices on top of that, you're gonna be falling behind.
speaker-0: Yeah. Sounds like you you're gonna be in a bad position either way, right? Like yeah. There is no skip. ⁓ so something something that is interesting that you mentioned it, ⁓ Richard is like if you know all of your infrastructure, right? Like and I think the problem for like ⁓ services like us, like like a managed service where we try to prioritize ⁓ all that kind of stuff is what is most challenging? The number of CVEs that are dropping the number of vulnerabilities that you have to track, or being able to fingerprint all of that to tell, like, hey, yeah, this is probably vulnerable, right? Because it's ⁓ it's hard. I know I know fingerprinting has been kind of an internal conversation for you and I, right? Like because fingerprinting is important for many tools we use and whatnot, right? So ⁓ do you see fingerprinting becoming even worse?
speaker-1: I do. I mean as especially with a lot of the vulnerabilities we've seen lately have not necessarily been internet facing exposures. Right. So when they're on the internet, we have a better shot at fingerprinting them. But a lot of them now we're behind off, SSOs involved, JWTs are blocking us. So we're we're finding more and more times it's harder and harder to know what you're truly running. And it's even worse ⁓ when you have when you have a situation where a certain version's vulnerable. And you can't version it, you have no choice but to tell the client they're vulnerable to everything, right? And we see this with scanners. We try not to do that. So it's really hard for us to dial in that version detection to make sure that we're telling them what they're vulnerable to truly and not just raising the alarms for for n for nothing. But yeah, fingerprinting is definitely ⁓ becoming more and more challenging as we find these issues affecting niche niche versions.
speaker-2: I I really wish they would just bring back a a version page that that people can see. I mean, I understand you don't wanna broadcast exactly what version you're running, but like it makes our job in life a whole lot easier if you do, but it also makes the bad guy's job a whole lot easier to do as well. So it's it is one of those things. If you're if you're proactive, I think everything every software should should broadcast what version they are because ⁓ you're you're proactively you know, patching yourself, but Is when you find that Apache from like two thousand and two that it still hasn't been updated and you're just like, hmm, I see. All right.
speaker-0: Yeah, I I see what I see why we don't do that anymore, right? Yeah. Yeah.
speaker-1: I could talk for hours of why s security by obscurity is not a better solution than just telling people what you're running, right? ⁓ especially when th these inside teams need to know this. They need to know what version I'm running. And I hate when I go to start building a detection process and then i it's like, hey, if you run this command on the box and it's like, well, yeah, if I'm on the box, I know what version I'm running. I I w what what if I'm not on the box though? ⁓ but yeah. Yeah.
speaker-2: We've we've seen customers even have trouble identifying what they're running, even when they have endpoint managers that literally have a shell in the box, they have to go physically run the version command for that particular s piece of software because these endpoint managers aren't ⁓ going through and categor cataloging everything that they're they're sitting on the host. So even if you have an endpoint manager, it's still not doing the full job, so it's it's rough. They customers still don't
speaker-0: Yeah.
speaker-1: And you've talked in the in the past, Sergio, especially with a lot of these newer vulnerabilities are impacting underlying libraries, not even the main software. You know, you talk about the NPM breach previously, and it's like those kind of things we just don't have a good way to identify without actually exporting the thing. So even understanding what libraries they're running in the versions is becoming more and more troublesome.
speaker-0: But and I think that there's a secondary problem in that, right? Like one thing is a supply chain attack where you know certain software is being delivered through your software, right? Kind of a that's why it's a supply chain. But sometimes you just have like ⁓ random embedded stuff, right? Like even even for normal normal users, I don't think they realize how many tools, libraries, and software it's installed on their own personal desktop, right? Like if you have if you have a ⁓ a Mac, you probably have ⁓ open SSL. You probably have bash, you probably have all of these pieces of software that used need to exist because that's how the operated system works. It's not that you want it on purpose to install that. It just exists. It's just in there, right? And is that and that's a problem. That's a kind of thin line between is that could that become a supply chain attack or or that's just how the system is built because there is no like systems are not like mono mono monolithic systems are kind of In the past, right? That doesn't exist anymore. Every system has a bunch of like embedded related stuff. ⁓ monolithic, not as in as in architecture, but monolithic as in being like single pieces of code running. More like that. Yeah, yeah. Sorry, for clarification. ⁓ because I I saw Kendrick like yeah, he didn't like that one. ⁓ so that's the problem, right? Like what do you do when when you're Apache, when you install Apache, all of the stuff that it needs to run ⁓ by default is is it's embedded, it's many libraries, right? Like it's hard to track all that. Like you have the problem of at the operating system, you have the problem at the application layer, you have the pro it's a lot, right? You have the problem at the network level, but if a vulnerability for the protocols themselves just happen, right? It's it's ⁓ it's a whole another deal. It's it's a lot to manage 100%. kind of the last question I had on on on this particular ⁓ history, right? Is the ⁓ for from all of the C Vs that dropped through Agos, right? There was ⁓ an specific SharePoint RC chain. It was C V E twenty twenty six five five ⁓ for and twenty twenty six six three five two right. ⁓ it was a couple of C Vs, RC SharePoint, right? Like trick you have critical infrastructure, you have RCE, you have ⁓ quote unquote easy vulnerabilities. ⁓ the worst thing is that ⁓ yeah. The patch Tuesday goes live and the same day a POC drop, right? So the the window to manage that, right, is like no. And like I I was already behind of the many volumes from July, August drop, and then a POC drop, right? Like, should we prioritize or is that a good strategy? You think like to prioritize based on I don't know, if there is a POC that's more important if you don't than if you don't have a C O POC, even though the risk might be lower based on like, you know, we have C V S S, we have different rating scores, right? Like though does that matter at all if you have a POC or not? Does it change today?
speaker-2: We've seen this happen before the so like the age of AI. We've we've seen this happen before. Like a C V E drops and then, you know, something somebody drops a proof of concept pretty quickly. But it's usually the person that found it, or at least somebody that is already looking at that piece of software found it. But now it's just like, ⁓ I go troll the C V E board and like I see a new one get posted, I go download the software and then send Claude at it or any other AI infrastructure and at it and It pops out a proof of concept based on this C V E bulletin description, and now I have it and now I can start go using it, right? So it's ⁓ it's it's it's pretty crazy ⁓ that these legacy ways of of risk score analysis are not gonna keep up. ⁓ I know we're probably gonna be talking about EPSS later on in this ⁓ little podcast, but ⁓ I I have some some some concerns with ⁓ those scores not being able to keep up with the reality of the current situation of how ⁓ fast everything is moving right now. Yeah.
speaker-1: I feel it is our responsibility as security practitioners to know when the right time to release something is. And I've really liked how Bishop Fox always errs on the side of the client and we don't release things publicly until they are fully patched and more than six hours have passed since the patch was dropped, right? you know, not again, not throwing shade to anyone who doesn't do that, but I think like we have we have rushed to be first so many times now in the industry. Not us, Bishop Fox, I'm saying the ethical hackers, we've rushed me first that we stopped asking, should we do this? Right. So if I get my research out before I get anyone else's out, now I'm the person that everyone goes to and I'm the one they ask questions to. But if I wait too long and someone else gets it out, now I look like I copied them even though it was my exploit. And that's where this chicken and egg race comes in where it's like, hey, I know they're releasing it Tuesday at four PM. My POC comes out Tuesday at five PM. And that's the end of it. And now I I I walk away from it and I'm okay. And then now every other blue teamer has to rush and fix what's happening. And like you were saying, do I prioritize the POC? I think maybe, but at the same time, it really depends on your risk tolerance. So for instance, you mentioned the two CVs. One of them was an internal ⁓ local attack only, and one of them was the off-bypass. Right? So it's like when you chain them together, they're really bad. But if you're focusing on the worst one, that is the you know external first. Then you mitigate the risk of the internal one. I'm not saying you prevent it, but you mitigate it. And then now the risk to that is even lower. So even though that there is a full chain, just focusing on the external one and blocking that that initial access, then I think is is the is the the the most important thing to do rather than patch everything. As we wrote in a blog post by Nate Robb, C VE feed is supposed to be a ⁓ a feed, not a checklist to be completed. So there's no reason to do every single C VE on there. Again. Patch, please patch, but not everything warrants a immediate response.
speaker-2: We've also seen ⁓ customers that have endpoint managers that are more sophisticated, ⁓ just take stuff offline from the external just right away. The C V E drops. We we know that it used to respond to us and then the C V E drops and then it no longer responds to us. We're like, wait a second. Yeah. Some some some customers of ours are pretty quick about it. So maybe maybe if that's ⁓ you know sounds good to you guys, ⁓ or listeners, ⁓ that Not you guys. The listeners. Yeah. Sounds good to be Yeah. ⁓ implement that. do do something more more ⁓ proactive and you know, be able to have the rigidity in your structures to be able to drop stuff off of e external communication quickly. So yeah. Or develop a procedure for that. So
speaker-1: Yeah, yeah.
speaker-0: Yeah. And particularly for non critical assets, right? Because I understand, right? You can take offline your banking system. Okay. Sure. ⁓
speaker-2: Actually no, take the banking system off.
speaker-1: Yeah, take it down. Save my money.
speaker-2: Yeah yeah.
speaker-0: Well yeah, that's not a that's not actually entirely ⁓ not entirely a joke, right? Like, hey, if you're gonna save my money by taking the banking offline, please do that, right? Like I I I see the risk benefit of that is like, yeah, sure, I prefer my money. I I I I don't know about the rest of the people would hundred percent. ⁓ but obviously there is systems that we cannot do that, right? Like ⁓ think about like mo ev even more critical than that. We call it critical because normally you want ⁓ to have availability on those assets at all times. Right. But it's not critical as in the world probably one stop, right? But but maybe we when we look at ⁓ an electrical plant ⁓ generating okay, that's different, right? A a water ⁓ water facility, cleaning water, right, for homes. Okay, maybe yeah, we you can't take it offline.
speaker-2: These things shouldn't be listening on the internet in the first place. I would just
speaker-1: gonna say that some of those things should not be on the internet.
speaker-2: I I think if you listen like a couple of podcasts ago we we talked about that I've for for one of the one of the companies was taken down because they had external stuff.
speaker-1: Yeah. I'm looking at you, forty client management ports. but ⁓ but yeah.
speaker-0: That that that's what what was going to say, right? Like if from the big beginning you don't or or if you could take it offline, maybe it doesn't need to be online, right?
speaker-1: That's the yeah, that's the better question to ask.
speaker-2: I'm I'm making a lot of assumptions here.
speaker-1: Yeah, hey, hey, I'm in. I like it. Hey, let's close the internet down. Kendrick said it, internet's closed for today.
speaker-2: But ⁓
speaker-0: ⁓ and and I think this is a great way to do our second ⁓ our second story for today, right? Like ⁓ whenever we are talking about we we have two pieces, right? We have the vulnerability intelligence part of the world. You have to manage all of these hundreds of C V E's and you need to be fast and patch every one of them, sure. ⁓ but you also have to defend against that attacks happening, right? Because actors are the ones using these C V E's, right? POC ⁓ SharePoint RCE, POC drop the same day, actors are using it. against your infrastructure, right? And the problem we have is like is defenders. Defenders have two two roles. One is to patch, to prevent, and here one is to react based on attacks they are seeing live. ⁓ something I'm seeing ⁓ happening in in terms of threat intelligence is like for some reason threat intelligence became kind of a similar situation where you have a list of one million IPs that are malicious that that you need to block right away. One ⁓ one million new hashes that you need to block because those are malicious and host that's how traditional AP systems ⁓ work, right? Like atomic indicators of compromise are becoming kind of a a similar problem where you can't prioritize IPs, you can't prioritize hashes, you can't prioritize these different unique items, right? There is a research I published in August where there was a ⁓ there was an analysis of close to two million IPs ⁓ cloud hosted IOCs attribution. And the problem is that there was ⁓ at least sixty providers that were hosting ⁓ malicious artifacts or were acting as common and control servers for at least 44 name tractors, right? And they were using like public known hyperscaler IP addresses, not not bulletproof hosts that are commonly known. So it's like should a company block Cloud for IPs? Should a company block Microsoft IPs? Should a comp like it's it's it's very hard, right? Like You will block legitimate traffic. So ⁓ I I personally, this is this kind of a personal thing. I have a problem with threat when when in the world in the cybersecurity industry you talk about like indicators of compromise, it's it's very similar, right? Like you are not attacking the root chaos, similar to a vulnerability. You are not attacking the root chaos, you are just patching something. The root cause is that you exposed it to the internet. This is a similar situation. You are reacting to block a million things. So ⁓ again, that's that's a personal preference. You shouldn't be just blocking millions of IPs. It makes sense as a reactive approach in an instant response, sure. ⁓
speaker-2: Well we we also kind of talked about in the past with residential proxies. We there was a vulnerability with ⁓ I think it was like some T V box or something like that. And they were being utilized as residential proxies. So now you're gonna start blocking legitimate customers because, you know, they got infected and they don't know any better or anything like that. ⁓ so yeah, like yeah.
speaker-0: Yeah. That's probably and I think that's the perfect scenario, right? Like a customer approaches you and he's like, hey, so I need your IOC fits, that's my tracking audience strategy. Like how do we feel about it, right? Like what conversation needs to happen with customers? How do educate the customers that IOCs are not necessarily the answer? Like blocking IOCs, atomic IOCs in general, is not a proper strategy for like protecting, right? Like how do you have those conversations with customers that are used to like thread fits used to in that?
speaker-1: Yeah. It's hard, right? It and it continues to get harder. The more that companies feed into these ideals, the more they become mainstream. And now you have to have this offering. Right. Bishop Fox preaches low noise. We preach less meaningless findings, right? And like you have clients say, Hey, cool, but I want the noise. I want that because this other thing has given me noise. And then you have to be like, Well, yeah, but they're they're false positives. You're not vulnerable to that. You're you're not actually being breached. Yes, these indicators say you're vulnerable, but I'm telling you right now, I tested it you're not. And like that's that argument we have with them. And we're seeing the same thing now as we transit tr transition into threat intelligence, right? Hey, what are you seeing being used against XYZ? And it's like, well, yeah, we're seeing that, but like other people also use that, not just as threat actor. And that's but hey, give me that feed like you're saying, give me that noise, let me sift through it and decide what's important and what's not important. But I don't know. That's a conversation that I think is gonna take other companies doing the same thing and not just chasing the dollar.
speaker-2: Also, IOCs are inherently noisy. Yeah. And and they're practically useless for a lot of these companies. Like sure they they can catch you like the file hashes, like yeah. The IPs, not so much. They they I I think ⁓ you might have mentioned that ⁓ these I they rotate their IPs fairly quickly in the first place. They're not they're not staying on that residential proxy for that long. ⁓ you know, it'll start raising questions with the local person of like, why is my internet so slow every day? And it's like, well, okay, so they cycle it off and you know, go on to the next victim. So I mean, it's one of those things where their value and noise, their value is pretty low, their noise is really high. It just doesn't seem like a great fit for a lot of companies these days to use them separately. ⁓ I think there's definitely an argument for utilizing them together ⁓ to help you. With this next stuff that we're about to talk about. But yeah, I man, all these things are so tied together. Great talking point. So yeah. Yeah. Yeah.
speaker-0: ⁓ and ⁓ for for me it's always like You cannot define your strategy based on reactive stuff, right? Like you need to to be more proactive, right? Like it's it's a similar situation. Like ⁓ yes, you need to patch, but maybe you don't need to expose certain levels of configuration. And in terms of like ⁓ vulnerability for vulnerability intelligence and for track intelligence, it's kind of similar. Yes, you can block an IP. If you have right now an incident response and there is a live IP, sure, block that IP, right? But the the underlying issue is you are not ready to cover the different TTPs that these actors are doing, right? Like make sure you have the the levels of detection. ⁓ like ⁓ that's that's why I I love TTPs in particular. I'm I'm a big fan of the the Metrial TTPs because like okay you can you can measure your strategy based on how many of the blocks you can cover, you can detect, right? Like it's it's easier to build a strategy based that way rather than just like the Try to patch everything, try to check back, right? Yeah, every C V is covered, try to like block every malicious IP ever seen, which is basically use millions, millions ⁓ of of IPs, right? Like it's it's kind of a yeah, you you kinda brought forth your way to protection. It will do nothing for you, basically.
speaker-1: Yeah. Well, for sure. And and I think, you know, ⁓ Kendrick mentioned rotating IPs. As a defender, when I get these indicators compromised, I'm looking back in my logs. I'm not I'm I shouldn't be looking forward. I'm not saying never, but like you're saying, when it when it comes from IP one dot one dot one dot one, I should be looking in my logs. Have I seen that IP? Not building Yarrow rules to block that IP in the future. Right? I'm not saying it won't become malicious again, but I've probably dumped it and moved on to a different Lambda box.
speaker-2: Yeah. Well you're also looking at the behavior of what that IP was doing, right? And then you build your R rule based on like, ⁓ they were, you know, spending this type of payload. I'm gonna build it to detect this type of payload so that when they recycle to like one one one one two or whatever, then you know, ⁓ now I can block that one just, you know, right off the bat. I only see one request for them from the IP and then I never have to worry about it again. And then you can just you know Building making sure you're building things smartly is is definitely one of those things where Your it's behavioral analysis that you want to block, not the immediate indicators. Unless like it's a you know a denial service and then you're just like, Well, I'm just gonna try to do that real quick so that you can get your stuff back up. ⁓ 'cause it's not it's denial service is like one of those edge special cases of ⁓ you know dealing with this type of ⁓ rules.
speaker-0: Which by the way we don't recommend you blocking one dot one. Nor eight.
speaker-2: Yeah. Yeah. Yeah, let's just go back to the previous point. If we just block everything external, you know, it's fine. You wanna talk to your neighbor's device, you gotta bring your physical cable over there, like you know.
speaker-1: Yeah, yeah. Gosh, yeah. Yeah, yeah. Like the old days, lamp parties. That's it.
speaker-0: So we we have we have kind of the the the worst of both worlds, right? Like vulnerability intelligence, we have a bunch of stuff. We how how how do we prioritize that? Vulnerity ⁓ intelligence, we have a similar situation. We have million IPs, which one should I build faster, right? So the question is, how do you scope all of those things, right? Like ⁓ apart from like getting a service like ⁓ the the the the managed services at Visual Fox, which help you do that, right? Well well other solutions you have, right? Because you have to do some parts on your own. It's it's your infrastructure, right? And we can cover we can cover so much, right? You still need anything on how to ⁓ feed from us all of this and how to react based on of all of this information. So ⁓ I don't know. There is ⁓ I I know we don't like C V S C B S S scoring. I don't we don't like the C V E standard scoring of the vulnerabilities. ⁓ for AOCs, there is no There is no ⁓ actual standard scoring, right? It's not like hey, you have a more malicious IP or something like that. You only have like external feeds that tell you like, yeah, we have seen this IP being malicious three times. Maybe the four ⁓ it's it's it's a good IP. I don't know, right? Like there Yeah. There's no standardization. So for one, we have too many standards where they are not ready for the real world, in my opinion. They are very static, right?
speaker-2: Yeah.
speaker-0: And for the other part, we don't have a standardized way of scoring how to feed your threat intelligence. So what's in it for customers? How would they prioritize this? Right? Like, should we look at, I don't know, CISA KV as the primary filter? Should we look at some someone else? Like who who is the who is the ruler in here? Who decides what priority? Right? Personally, it depends on the company by itself, ⁓ for started, right? Like if you are If you are an a ⁓ company in Europe, well look at the Europe kind of ⁓ CISA equ equivalent. I don't know if there is a CISA equivalent in Europe. ⁓ if you're in the US, well maybe CISA is a good idea. ⁓ and for third intelligence, look and discern based on like, hey, are these sectors really attacking my region? For starters, right? Like to see what to do. But I don't know. How how do you feel about this, guys?
speaker-2: I I felt really good about EPSS exploit predictivity something something. ⁓ an acronym, but ⁓ basically trying to predict whether or not a a C B E will be utilized in the near short term. ⁓ so I I had really good looking at ⁓ I felt really good about it look ⁓ like recently up until like probably like three or so months ago. ⁓ mainly just because of the acceleration of AI assisted exploit development. ⁓ I f feel as though the score the EPSS score is not keeping up with the actual reality that we're seeing on the ground right now. And that's kind of unfortunate because I I we were utilizing EPSS for a little while before ⁓ this whole AI revolution thing happened. And I'm gonna keep on calling it that because ⁓ it really ⁓ it did revolutionize ⁓ who how accessible. ⁓ exploit dev and all that type of stuff was, ⁓ or is, I guess, now. So it I don't know. I feel like we're gonna have to have like an EPSS version two here soon, ⁓ that maybe ⁓ is a little bit looser on its ⁓ or maybe they redefine how they're scoring them and saying if they're gonna be actually be exploitable or exploited.
speaker-1: Yeah. Man, latest CVEs. But but yeah, j just to bounce off that, right? If we're using EBSS scores and the Kev, right? The the non-exploited vulnerabilities. I think both of those are too late. By the time those scores are high or they are true, you are already been exposed and possibly exploited by these things. Right. So retroactively, if it goes to Kev That should ramp up your your decision to action it. But it's already almost too late when those numbers get high. When that hits when it hits a high number, chances are you you've been exploited by it or a lot's going on. And don't get me started with with with the known exploited vulnerabilities. If you read their their rules about what they determined to be exploitable, they do count legitimate scan trap, not scanners, but traffic scanning for it that does not truly exploit it. That's a failed exploit attempt, counts as Kev. If have other companies doing the same thing, they toss up honey pots, and now they're saying this is known exploited vulnerability because they're seeing traffic for it. So the truth of what you're seeing no longer resides in one authority and now it's a bunch of them, right? But but yeah, when those two things come together, it's too late. And now you need a new scoring metric. I hate to go back to fingerprinting, but like that's what you gotta do is understand your attack surface to know what your true impact is and what you are truly vulnerable to. And when SharePoint comes out. And you only use SharePoint cloud services, you can ignore that C V E because you know you're not vulnerable to it because it wasn't vulnerable to the two cloud assets. But otherwise, yeah. I I think like Kidrick was saying, it it can't keep up. We had ⁓ what, I think the first half of this year already had like 30,000 CVEs issued in H1 of this year, and that's just like that was the totality of last year. It's just it's just ⁓ astronomical. And we've seen this repeated issue at like disable ASLR and it's exploitable. It's like, yeah, well I'm not I gotta disable it though. And if you if you disable it in production, you probably should be exploited. I'm no no you shouldn't. No you shouldn't. But if you disable the security controls to make it easier for you to implement it, that's not a vulnerability, right? That's a misconfiguration.
speaker-0: Yeah. Which and we go back to another current, right? Like the CWEs and how do you how do you approach those? Because ⁓ similar to ⁓ to to Wasp top ten, right? Like they are not run everything per se, but they are things you should be doing and it's hardening and it's it's a lot. It's it's it's really a lot of work for for the folks out there trying to manage a lot the infrastructure, right?
speaker-1: Yeah.
speaker-2: I think we've gone full circle and we're right back to C BSS scores being like the way that you determine whether or not you should patch because we we were really excited about EPSS and Sisakev and then now now we kinda we we skipped over that time period of of those being useful at this point. I ⁓ yeah unfortunately. Until a new metric comes out, ⁓ C BSS scoring might honestly be the the answer for most corporations to figure out whether or not they should patch, which is Unfortunate because it wasn't a great solution in the first place, but the acceleration that we've seen in the last six months is is too much.
speaker-0: Yeah. Yeah. And I'm kind of quickly going back to ⁓ Richard comment of like, ⁓ if you have SharePoint on the clouds, maybe you shouldn't worry. Which I kind of agree, but at the same time, it's like then how do I prioritize if I have infrastructure? Because current companies have infrastructure everywhere. They have they have like on premise, they have clouds, they have ⁓ SaaS, PaaS, like they have everything, right? Like which one should you be looking at first? Which one is more critical, right? Like how do you define those thin lines between all of your shared infrastructure across all of the different type of infrastructure that you have now.
speaker-1: Yeah. And I think this is where, you know, we get to nerd out. We talk about these levels of the onion, right? So it's like cool, okay. We have on-prem and we have SaaS stuff. The on-prem stuff, I'm I'm I'm risking the hardware and the software together. Whereas or sorry, the hardware, software and data, right? I own all three of those. Lease the software, what do you want to say? The cloud assets, I only own the data, right? The infrastructure is managed by someone else. So, in my opinion, if I am on the cloud stuff and vulnerabilities come out with air, the data loss is my risk. And if I can o if I'm okay with the data that's going to be exposed there, it's not client data, it's benign metrics, I'm doing some kind of tracking. I'm okay. That's not a threat to me. It is a risk. It's going to hit my brand a little bit, but not take me under. Whereas if I own the infrastructure, And I get popped by this thing, and now I have someone living on my land that I can't catch, that's a higher risk. So I always gonna err on a site of on-prem should take priority over any cloud assets because it's just a data loss thing. Yes, we can get in semantics of client data and HIPAA regulations and those kind of things. I'm not saying those aren't important, but losing that data and being able to quantify that versus losing that data, having someone live on my service ⁓ on my server and now moving around laterally in my infrastructure. causing more data loss and more server compromise, I'd say every day of the week, internal systems need priority over over cloud assets.
speaker-2: We well, we've also seen remediation take precedence in the cloud. So Bug Bounty or whatever reports it to the cloud. Cloud patches it literally before they announce it, because they control the software and the patch. They patch it, announce it, and you're good to go, right? And they leave ⁓ all their customers that aren't in the cloud out to just deal with it. we've seen that happen quite a few times where they have patched it in the cloud, released it for on-prem But they released it all at the same time and it's just like, okay, well, all these on prem ones are now up for grabs for somebody to go and get them. And it's that it's it's also a a cost analysis because obviously, you know, some some companies don't want to put things in the cloud. Some people some companies do want to put stuff in the cloud. It's it's really one of those things where maybe it's starting to become more beneficial with how fast ⁓ vulnerabilities are getting created or not created. But exploit found and exploitable, ⁓ that it might be worth moving everything to the cloud just to minimize risk. Yeah. Just like like you get the patch first and ⁓ you're never exploited is kind of a good thing, but I also don't like putting things in the cloud. I personally don't like putting things in the cloud, ⁓ but you know, it is what it is. I'm also not running a company, so
speaker-0: Yeah. Yeah. I think like yeah it's also important, right, like to understand what type of cloak you have. Because there's a certain we go back to like the the misconfiguration, the C D CWE model, right? Like something like Salesforce, for example, you need to do a lot of like fine tuning because otherwise it's like empty and it's it exposes a lot of things. Not in a bad way, but that's how it works, right? Like ⁓ you need to actually do some coding on it to be like
speaker-1: Yeah.
speaker-0: properly secure and whatnot. There is a shared responsibility model for every cloud provider to see what's on your end to result and what's on their end result. Right. Like it it really depends on the type of cloud you are you are dealing with. Right. And for threat for for threat related intelligence it's kind of similar, right? Like ⁓ you normal you don't really want to prioritize those actors that are active right now. Because even today I've seen like companies publishing like hey yeah So so three is traductor, Carbon Act. And it's like, yeah, Carbon Act Fin seven has not been active necessarily for a while, or it has been spun off into other type of tractors, related actors, but not the same original Carbon Act. So you don't really need to protect against those specific C TPs anymore, right? Like maybe it's too old. It's like a two thousand eight act. that that that that went active for for a long time, right? But it's not as it's not as much of a priority as something like ⁓ shiny hunters, right? Like we talk about shiny hunters every week. I think I so so maybe that that's how you need to evaluate. One is the timing is is what will give you precision. And thirteen is like ⁓ I think almost almost every working professional for years in the cybersecurity field has been the ⁓ The pyramid of pain, ⁓ where you talk about like how easy is to block IPs, how easy is to block hashes. But the really challenging part is to look at the TTPs, right? And see how actors really work. I think that's the model we should still follow. I think it's a valid model because there is no wha what is more risky, shiny hunters or IPT forty two? Well, it depends, right? Who you are. Are you are you a government organization? Maybe you need to look at APT. ⁓ for it too, right? Are you and school? Okay, look at China, right? It it it's ⁓ that's why I say all right, I wish we had a system like and it's core I wish I had C VSS for trade actors, honestly. That that'd be it.
speaker-1: Yeah, and and and that raises, you know, ⁓ another bar for we talked earlier about how teams do this. How how do how do teams manage that? How how do teams using even a threat and cell feed know which threat actors I should be watching? Like is that something that that is known in the industry or is that something that you, Sergio, having knowledge of ⁓ T T P and interactive relations is able to explain better.
speaker-0: I believe it's someone that needs to have certain knowledge to do that. Or the company needs to set those intelligence requirements to be able to it's cope that. It's not it's not as as normal or standard as patching C V E's, right? That's a more normal thing in cybersecurity world. But yeah. ⁓ cool. I think this is a this is a great opportunity for us to wrap. ⁓ it was a great
speaker-1: All day.
speaker-0: Yeah, yeah, we we will be talking about this all day. This was a great conversation. ⁓ three things I think I will be walking away with. One is patch window is no longer a window, right? It's like, yeah, you you you have no time anymore. Atomic IUCs and blocking tours. It's not an intelligence program per se. You need to do more, you need to learn TTPs and what behavior the the actors are doing. ⁓ yeah. Scoping for both. Vulnerability and threatening lens is the only thing that will make those problems manageable. Right. so again, thank you, Kendrick, thank you, Richard, for joining us. ⁓ my name is Sergei Villegas. I was your host today. I hope to see you in the next MSS episode. And remember, you can find us in the Pigeonfox Discord, subreddit, ⁓ links will be on the notes. And that's it. See you next time.
speaker-1: Two minute, two minutes.
speaker-0: Too many. Yeah. ⁓ we're gonna talk why ⁓ the way most teams consume tech intelligence is broken, right? ⁓ something that it's always in my head is like atomic indicators of compromise. Are they wordless? Kind of, maybe. We will see that. ⁓ finally we will discuss a bit of ⁓ what ⁓ how to not necessarily how to, but what is actually ⁓ what it means to scope your Intel program. So yeah, so you can get something useful from it. So ⁓ I'm Sergio Villegas, ⁓ Senior Managing Managing Analyst analyst. I'm joined today by Richard Brown, Senior Managing Operator, and Kendrick Urbanag Urbanak as senior operator. So welcome guys. How are you?
speaker-1: Good, good. Thanks for having us as always, man.
speaker-0: Yeah, it's great. ⁓ I think time will by really fast. Another month, another MSS episode. ⁓ this is the second episode. I'm I'm excited we didn't got cancelled last time.
speaker-1: We normally get ⁓ the pilot and then a couple episodes, right? Character building. The character building episodes.
speaker-2: Yeah, yeah.
speaker-0: That's a plan. ⁓ some ⁓ quick updates and and shoutouts for the team. ⁓ we are going to have some events ⁓ where many of the foxes ⁓ will be participating. ⁓ so please when when you are seen ⁓ when you are hearing us, if you're hearing us ⁓ the when we release this episode, we will have Patricio Sanchez, he will be speaking at the FIIAC. It's ⁓ conference in Mexico. ⁓ he's gonna bu he's gonna be talking about like zero trust identity data protection. So hope to meet ⁓ you guys in there. It's gonna be a good one. This is gonna be in Mexico. So really good to see this. ⁓ we will also have ⁓ Salvador Rodriguez, he's going to Pownet CR. This is a Costa Rica event. So yeah, we are going more international now, right? Like covering ⁓ other conferences beyond we always cover DEF CON, we always always cover the big ones, but we also cover very ⁓ regional specific events. We we like the community, so we will do that. He will be talking about ⁓ building real world offensive security automations with agents, skills, MCP. So yeah, you know, all of the AI stuff we we like in initial access. ⁓ also for next week we have Samantha Randa. She will be on our Discord. So also ⁓ don't forget to join our Discord or Discord or subreddit. ⁓ she will be leading a couple of ⁓ workshops in there. ⁓ first one will be in English September fifteenth. Second one will be in Spanish September seventeenth. ⁓ she will ⁓ she will do some ⁓ the workshop is about weaponizing co formation. ⁓ yeah, it will be a lot of like AWS offensive skills. It will be great, right? Like I'm I'm really happy to to see us scoring not only the English world but also the Spanish one. ⁓ if you don't know, right, like Beach of Fox has a lot of like team members from other re regions beyond ⁓ the US. So it's cool to see that. ⁓ so yeah, I think that's a great ⁓ yeah talking about like offensive skills, talking about like everything that is bad in the world. This is a great segue to our first story, right? Like what happened between last time we talked, last month, to today, right? ⁓ It's been four or five weeks if I remember correctly. Yeah. So we saw the I was I was patched and actually as this episode is being recorded, there is another patch Tuesday that went live. So we're not talking about today's patch. We're talking about till the previous one in August. So it was a lot, right?
speaker-1: Yeah.
speaker-0: ⁓ it was one of the l largest in history. ⁓ there was over a hund over four hundred CDEs in Microsoft products alone. Hundred eight of them were rated critical. ⁓ this is ⁓ yeah, this is a twelve month average. in the in the twelve month average is around eighteen critical, but this time a hundred eight. It's a lot, right? It's a lot of vulnerabilities. ⁓ we also ⁓ had some very specific ⁓ vulnerabilities ⁓ already exploited in the wild. ⁓ so the CSA key key we listed them. So it it was kind of a really wild wild quest for Agos in terms of like ⁓ vulnerabilities being disclosed. And I know last time we talked about vulnerability intelligence, right? So the real question in here, ⁓ what do we do? Right? Like I have a four hundred vulnerabilities. I can't cover all of them in a single month. And this one we have hundreds more, right? Like How do you manage to triage all of that in a realistic time frame? Right? What does the or how does the workflow of of managing all of that look like when it's at high, right? Like what do you do? Where do you start? ⁓ is there an end to it whenever you're managing Google this? I know. What what are your thoughts, guy?
speaker-2: I think for the most part no, th th it's not manageable to to do four hundred and something CPEs in a in a month. ⁓ you're gonna end up applying pat patches blindly and you're gonna hope it doesn't break anything, and then when it does break something, you roll it back and you go on in patch number four hundred and twenty two and then you hope that one doesn't break anything and then you keep on going and rolling it forward. I mean ⁓ this month is gonna be even worse for for Blue team and patching things, like that's it's not gonna be a whole lot of fun patching a thousand different things. Hopefully, ⁓ they can roll those all into one, but it's not looking great right now.
speaker-1: And and that's even if you understand your infrastructure enough to know if it's gonna break anything downstream. Right. ⁓ I think that's one of the reasons why most places have like a thirty day window between patches for n for non critical things. Don't don't wait thirty days for critical things. But they have that window because they're trying to figure out what's gonna break when they patch this. And I think we are getting a little further away from the days of having that one server that has an uptime of six hundred days, but ⁓ we're not far, you know, we're not that far away from it. So Definitely tough. AI has increased exponentially the amount of C V E's we have to deal with on a daily basis. And I feel bad for internal teams because I like Kendrick was saying, I don't know how you're gonna do it. ⁓ physically understanding your attack surface to know which patch to put in priority of the other one is a job in itself. And if you're doing other things like managing networks, you're gonna be falling behind. Or should I say managing devices on top of that, you're gonna be falling behind.
speaker-0: Yeah. Sounds like you you're gonna be in a bad position either way, right? Like yeah. There is no skip. ⁓ so something something that is interesting that you mentioned it, ⁓ Richard is like if you know all of your infrastructure, right? Like and I think the problem for like ⁓ services like us, like like a managed service where we try to prioritize ⁓ all that kind of stuff is what is most challenging? The number of CVEs that are dropping the number of vulnerabilities that you have to track, or being able to fingerprint all of that to tell, like, hey, yeah, this is probably vulnerable, right? Because it's ⁓ it's hard. I know I know fingerprinting has been kind of an internal conversation for you and I, right? Like because fingerprinting is important for many tools we use and whatnot, right? So ⁓ do you see fingerprinting becoming even worse?
speaker-1: I do. I mean as especially with a lot of the vulnerabilities we've seen lately have not necessarily been internet facing exposures. Right. So when they're on the internet, we have a better shot at fingerprinting them. But a lot of them now we're behind off, SSOs involved, JWTs are blocking us. So we're we're finding more and more times it's harder and harder to know what you're truly running. And it's even worse ⁓ when you have when you have a situation where a certain version's vulnerable. And you can't version it, you have no choice but to tell the client they're vulnerable to everything, right? And we see this with scanners. We try not to do that. So it's really hard for us to dial in that version detection to make sure that we're telling them what they're vulnerable to truly and not just raising the alarms for for n for nothing. But yeah, fingerprinting is definitely ⁓ becoming more and more challenging as we find these issues affecting niche niche versions.
speaker-2: I I really wish they would just bring back a a version page that that people can see. I mean, I understand you don't wanna broadcast exactly what version you're running, but like it makes our job in life a whole lot easier if you do, but it also makes the bad guy's job a whole lot easier to do as well. So it's it is one of those things. If you're if you're proactive, I think everything every software should should broadcast what version they are because ⁓ you're you're proactively you know, patching yourself, but Is when you find that Apache from like two thousand and two that it still hasn't been updated and you're just like, hmm, I see. All right.
speaker-0: Yeah, I I see what I see why we don't do that anymore, right? Yeah. Yeah.
speaker-1: I could talk for hours of why s security by obscurity is not a better solution than just telling people what you're running, right? ⁓ especially when th these inside teams need to know this. They need to know what version I'm running. And I hate when I go to start building a detection process and then i it's like, hey, if you run this command on the box and it's like, well, yeah, if I'm on the box, I know what version I'm running. I I w what what if I'm not on the box though? ⁓ but yeah. Yeah.
speaker-2: We've we've seen customers even have trouble identifying what they're running, even when they have endpoint managers that literally have a shell in the box, they have to go physically run the version command for that particular s piece of software because these endpoint managers aren't ⁓ going through and categor cataloging everything that they're they're sitting on the host. So even if you have an endpoint manager, it's still not doing the full job, so it's it's rough. They customers still don't
speaker-0: Yeah.
speaker-1: And you've talked in the in the past, Sergio, especially with a lot of these newer vulnerabilities are impacting underlying libraries, not even the main software. You know, you talk about the NPM breach previously, and it's like those kind of things we just don't have a good way to identify without actually exporting the thing. So even understanding what libraries they're running in the versions is becoming more and more troublesome.
speaker-0: But and I think that there's a secondary problem in that, right? Like one thing is a supply chain attack where you know certain software is being delivered through your software, right? Kind of a that's why it's a supply chain. But sometimes you just have like ⁓ random embedded stuff, right? Like even even for normal normal users, I don't think they realize how many tools, libraries, and software it's installed on their own personal desktop, right? Like if you have if you have a ⁓ a Mac, you probably have ⁓ open SSL. You probably have bash, you probably have all of these pieces of software that used need to exist because that's how the operated system works. It's not that you want it on purpose to install that. It just exists. It's just in there, right? And is that and that's a problem. That's a kind of thin line between is that could that become a supply chain attack or or that's just how the system is built because there is no like systems are not like mono mono monolithic systems are kind of In the past, right? That doesn't exist anymore. Every system has a bunch of like embedded related stuff. ⁓ monolithic, not as in as in architecture, but monolithic as in being like single pieces of code running. More like that. Yeah, yeah. Sorry, for clarification. ⁓ because I I saw Kendrick like yeah, he didn't like that one. ⁓ so that's the problem, right? Like what do you do when when you're Apache, when you install Apache, all of the stuff that it needs to run ⁓ by default is is it's embedded, it's many libraries, right? Like it's hard to track all that. Like you have the problem of at the operating system, you have the problem at the application layer, you have the pro it's a lot, right? You have the problem at the network level, but if a vulnerability for the protocols themselves just happen, right? It's it's ⁓ it's a whole another deal. It's it's a lot to manage 100%. kind of the last question I had on on on this particular ⁓ history, right? Is the ⁓ for from all of the C Vs that dropped through Agos, right? There was ⁓ an specific SharePoint RC chain. It was C V E twenty twenty six five five ⁓ for and twenty twenty six six three five two right. ⁓ it was a couple of C Vs, RC SharePoint, right? Like trick you have critical infrastructure, you have RCE, you have ⁓ quote unquote easy vulnerabilities. ⁓ the worst thing is that ⁓ yeah. The patch Tuesday goes live and the same day a POC drop, right? So the the window to manage that, right, is like no. And like I I was already behind of the many volumes from July, August drop, and then a POC drop, right? Like, should we prioritize or is that a good strategy? You think like to prioritize based on I don't know, if there is a POC that's more important if you don't than if you don't have a C O POC, even though the risk might be lower based on like, you know, we have C V S S, we have different rating scores, right? Like though does that matter at all if you have a POC or not? Does it change today?
speaker-2: We've seen this happen before the so like the age of AI. We've we've seen this happen before. Like a C V E drops and then, you know, something somebody drops a proof of concept pretty quickly. But it's usually the person that found it, or at least somebody that is already looking at that piece of software found it. But now it's just like, ⁓ I go troll the C V E board and like I see a new one get posted, I go download the software and then send Claude at it or any other AI infrastructure and at it and It pops out a proof of concept based on this C V E bulletin description, and now I have it and now I can start go using it, right? So it's ⁓ it's it's it's pretty crazy ⁓ that these legacy ways of of risk score analysis are not gonna keep up. ⁓ I know we're probably gonna be talking about EPSS later on in this ⁓ little podcast, but ⁓ I I have some some some concerns with ⁓ those scores not being able to keep up with the reality of the current situation of how ⁓ fast everything is moving right now. Yeah.
speaker-1: I feel it is our responsibility as security practitioners to know when the right time to release something is. And I've really liked how Bishop Fox always errs on the side of the client and we don't release things publicly until they are fully patched and more than six hours have passed since the patch was dropped, right? you know, not again, not throwing shade to anyone who doesn't do that, but I think like we have we have rushed to be first so many times now in the industry. Not us, Bishop Fox, I'm saying the ethical hackers, we've rushed me first that we stopped asking, should we do this? Right. So if I get my research out before I get anyone else's out, now I'm the person that everyone goes to and I'm the one they ask questions to. But if I wait too long and someone else gets it out, now I look like I copied them even though it was my exploit. And that's where this chicken and egg race comes in where it's like, hey, I know they're releasing it Tuesday at four PM. My POC comes out Tuesday at five PM. And that's the end of it. And now I I I walk away from it and I'm okay. And then now every other blue teamer has to rush and fix what's happening. And like you were saying, do I prioritize the POC? I think maybe, but at the same time, it really depends on your risk tolerance. So for instance, you mentioned the two CVs. One of them was an internal ⁓ local attack only, and one of them was the off-bypass. Right? So it's like when you chain them together, they're really bad. But if you're focusing on the worst one, that is the you know external first. Then you mitigate the risk of the internal one. I'm not saying you prevent it, but you mitigate it. And then now the risk to that is even lower. So even though that there is a full chain, just focusing on the external one and blocking that that initial access, then I think is is the is the the the most important thing to do rather than patch everything. As we wrote in a blog post by Nate Robb, C VE feed is supposed to be a ⁓ a feed, not a checklist to be completed. So there's no reason to do every single C VE on there. Again. Patch, please patch, but not everything warrants a immediate response.
speaker-2: We've also seen ⁓ customers that have endpoint managers that are more sophisticated, ⁓ just take stuff offline from the external just right away. The C V E drops. We we know that it used to respond to us and then the C V E drops and then it no longer responds to us. We're like, wait a second. Yeah. Some some some customers of ours are pretty quick about it. So maybe maybe if that's ⁓ you know sounds good to you guys, ⁓ or listeners, ⁓ that Not you guys. The listeners. Yeah. Sounds good to be Yeah. ⁓ implement that. do do something more more ⁓ proactive and you know, be able to have the rigidity in your structures to be able to drop stuff off of e external communication quickly. So yeah. Or develop a procedure for that. So
speaker-1: Yeah, yeah.
speaker-0: Yeah. And particularly for non critical assets, right? Because I understand, right? You can take offline your banking system. Okay. Sure. ⁓
speaker-2: Actually no, take the banking system off.
speaker-1: Yeah, take it down. Save my money.
speaker-2: Yeah yeah.
speaker-0: Well yeah, that's not a that's not actually entirely ⁓ not entirely a joke, right? Like, hey, if you're gonna save my money by taking the banking offline, please do that, right? Like I I I see the risk benefit of that is like, yeah, sure, I prefer my money. I I I I don't know about the rest of the people would hundred percent. ⁓ but obviously there is systems that we cannot do that, right? Like ⁓ think about like mo ev even more critical than that. We call it critical because normally you want ⁓ to have availability on those assets at all times. Right. But it's not critical as in the world probably one stop, right? But but maybe we when we look at ⁓ an electrical plant ⁓ generating okay, that's different, right? A a water ⁓ water facility, cleaning water, right, for homes. Okay, maybe yeah, we you can't take it offline.
speaker-2: These things shouldn't be listening on the internet in the first place. I would just
speaker-1: gonna say that some of those things should not be on the internet.
speaker-2: I I think if you listen like a couple of podcasts ago we we talked about that I've for for one of the one of the companies was taken down because they had external stuff.
speaker-1: Yeah. I'm looking at you, forty client management ports. but ⁓ but yeah.
speaker-0: That that that's what what was going to say, right? Like if from the big beginning you don't or or if you could take it offline, maybe it doesn't need to be online, right?
speaker-1: That's the yeah, that's the better question to ask.
speaker-2: I'm I'm making a lot of assumptions here.
speaker-1: Yeah, hey, hey, I'm in. I like it. Hey, let's close the internet down. Kendrick said it, internet's closed for today.
speaker-2: But ⁓
speaker-0: ⁓ and and I think this is a great way to do our second ⁓ our second story for today, right? Like ⁓ whenever we are talking about we we have two pieces, right? We have the vulnerability intelligence part of the world. You have to manage all of these hundreds of C V E's and you need to be fast and patch every one of them, sure. ⁓ but you also have to defend against that attacks happening, right? Because actors are the ones using these C V E's, right? POC ⁓ SharePoint RCE, POC drop the same day, actors are using it. against your infrastructure, right? And the problem we have is like is defenders. Defenders have two two roles. One is to patch, to prevent, and here one is to react based on attacks they are seeing live. ⁓ something I'm seeing ⁓ happening in in terms of threat intelligence is like for some reason threat intelligence became kind of a similar situation where you have a list of one million IPs that are malicious that that you need to block right away. One ⁓ one million new hashes that you need to block because those are malicious and host that's how traditional AP systems ⁓ work, right? Like atomic indicators of compromise are becoming kind of a a similar problem where you can't prioritize IPs, you can't prioritize hashes, you can't prioritize these different unique items, right? There is a research I published in August where there was a ⁓ there was an analysis of close to two million IPs ⁓ cloud hosted IOCs attribution. And the problem is that there was ⁓ at least sixty providers that were hosting ⁓ malicious artifacts or were acting as common and control servers for at least 44 name tractors, right? And they were using like public known hyperscaler IP addresses, not not bulletproof hosts that are commonly known. So it's like should a company block Cloud for IPs? Should a company block Microsoft IPs? Should a comp like it's it's it's very hard, right? Like You will block legitimate traffic. So ⁓ I I personally, this is this kind of a personal thing. I have a problem with threat when when in the world in the cybersecurity industry you talk about like indicators of compromise, it's it's very similar, right? Like you are not attacking the root chaos, similar to a vulnerability. You are not attacking the root chaos, you are just patching something. The root cause is that you exposed it to the internet. This is a similar situation. You are reacting to block a million things. So ⁓ again, that's that's a personal preference. You shouldn't be just blocking millions of IPs. It makes sense as a reactive approach in an instant response, sure. ⁓
speaker-2: Well we we also kind of talked about in the past with residential proxies. We there was a vulnerability with ⁓ I think it was like some T V box or something like that. And they were being utilized as residential proxies. So now you're gonna start blocking legitimate customers because, you know, they got infected and they don't know any better or anything like that. ⁓ so yeah, like yeah.
speaker-0: Yeah. That's probably and I think that's the perfect scenario, right? Like a customer approaches you and he's like, hey, so I need your IOC fits, that's my tracking audience strategy. Like how do we feel about it, right? Like what conversation needs to happen with customers? How do educate the customers that IOCs are not necessarily the answer? Like blocking IOCs, atomic IOCs in general, is not a proper strategy for like protecting, right? Like how do you have those conversations with customers that are used to like thread fits used to in that?
speaker-1: Yeah. It's hard, right? It and it continues to get harder. The more that companies feed into these ideals, the more they become mainstream. And now you have to have this offering. Right. Bishop Fox preaches low noise. We preach less meaningless findings, right? And like you have clients say, Hey, cool, but I want the noise. I want that because this other thing has given me noise. And then you have to be like, Well, yeah, but they're they're false positives. You're not vulnerable to that. You're you're not actually being breached. Yes, these indicators say you're vulnerable, but I'm telling you right now, I tested it you're not. And like that's that argument we have with them. And we're seeing the same thing now as we transit tr transition into threat intelligence, right? Hey, what are you seeing being used against XYZ? And it's like, well, yeah, we're seeing that, but like other people also use that, not just as threat actor. And that's but hey, give me that feed like you're saying, give me that noise, let me sift through it and decide what's important and what's not important. But I don't know. That's a conversation that I think is gonna take other companies doing the same thing and not just chasing the dollar.
speaker-2: Also, IOCs are inherently noisy. Yeah. And and they're practically useless for a lot of these companies. Like sure they they can catch you like the file hashes, like yeah. The IPs, not so much. They they I I think ⁓ you might have mentioned that ⁓ these I they rotate their IPs fairly quickly in the first place. They're not they're not staying on that residential proxy for that long. ⁓ you know, it'll start raising questions with the local person of like, why is my internet so slow every day? And it's like, well, okay, so they cycle it off and you know, go on to the next victim. So I mean, it's one of those things where their value and noise, their value is pretty low, their noise is really high. It just doesn't seem like a great fit for a lot of companies these days to use them separately. ⁓ I think there's definitely an argument for utilizing them together ⁓ to help you. With this next stuff that we're about to talk about. But yeah, I man, all these things are so tied together. Great talking point. So yeah. Yeah. Yeah.
speaker-0: ⁓ and ⁓ for for me it's always like You cannot define your strategy based on reactive stuff, right? Like you need to to be more proactive, right? Like it's it's a similar situation. Like ⁓ yes, you need to patch, but maybe you don't need to expose certain levels of configuration. And in terms of like ⁓ vulnerability for vulnerability intelligence and for track intelligence, it's kind of similar. Yes, you can block an IP. If you have right now an incident response and there is a live IP, sure, block that IP, right? But the the underlying issue is you are not ready to cover the different TTPs that these actors are doing, right? Like make sure you have the the levels of detection. ⁓ like ⁓ that's that's why I I love TTPs in particular. I'm I'm a big fan of the the Metrial TTPs because like okay you can you can measure your strategy based on how many of the blocks you can cover, you can detect, right? Like it's it's easier to build a strategy based that way rather than just like the Try to patch everything, try to check back, right? Yeah, every C V is covered, try to like block every malicious IP ever seen, which is basically use millions, millions ⁓ of of IPs, right? Like it's it's kind of a yeah, you you kinda brought forth your way to protection. It will do nothing for you, basically.
speaker-1: Yeah. Well, for sure. And and I think, you know, ⁓ Kendrick mentioned rotating IPs. As a defender, when I get these indicators compromised, I'm looking back in my logs. I'm not I'm I shouldn't be looking forward. I'm not saying never, but like you're saying, when it when it comes from IP one dot one dot one dot one, I should be looking in my logs. Have I seen that IP? Not building Yarrow rules to block that IP in the future. Right? I'm not saying it won't become malicious again, but I've probably dumped it and moved on to a different Lambda box.
speaker-2: Yeah. Well you're also looking at the behavior of what that IP was doing, right? And then you build your R rule based on like, ⁓ they were, you know, spending this type of payload. I'm gonna build it to detect this type of payload so that when they recycle to like one one one one two or whatever, then you know, ⁓ now I can block that one just, you know, right off the bat. I only see one request for them from the IP and then I never have to worry about it again. And then you can just you know Building making sure you're building things smartly is is definitely one of those things where Your it's behavioral analysis that you want to block, not the immediate indicators. Unless like it's a you know a denial service and then you're just like, Well, I'm just gonna try to do that real quick so that you can get your stuff back up. ⁓ 'cause it's not it's denial service is like one of those edge special cases of ⁓ you know dealing with this type of ⁓ rules.
speaker-0: Which by the way we don't recommend you blocking one dot one. Nor eight.
speaker-2: Yeah. Yeah. Yeah, let's just go back to the previous point. If we just block everything external, you know, it's fine. You wanna talk to your neighbor's device, you gotta bring your physical cable over there, like you know.
speaker-1: Yeah, yeah. Gosh, yeah. Yeah, yeah. Like the old days, lamp parties. That's it.
speaker-0: So we we have we have kind of the the the worst of both worlds, right? Like vulnerability intelligence, we have a bunch of stuff. We how how how do we prioritize that? Vulnerity ⁓ intelligence, we have a similar situation. We have million IPs, which one should I build faster, right? So the question is, how do you scope all of those things, right? Like ⁓ apart from like getting a service like ⁓ the the the the managed services at Visual Fox, which help you do that, right? Well well other solutions you have, right? Because you have to do some parts on your own. It's it's your infrastructure, right? And we can cover we can cover so much, right? You still need anything on how to ⁓ feed from us all of this and how to react based on of all of this information. So ⁓ I don't know. There is ⁓ I I know we don't like C V S C B S S scoring. I don't we don't like the C V E standard scoring of the vulnerabilities. ⁓ for AOCs, there is no There is no ⁓ actual standard scoring, right? It's not like hey, you have a more malicious IP or something like that. You only have like external feeds that tell you like, yeah, we have seen this IP being malicious three times. Maybe the four ⁓ it's it's it's a good IP. I don't know, right? Like there Yeah. There's no standardization. So for one, we have too many standards where they are not ready for the real world, in my opinion. They are very static, right?
speaker-2: Yeah.
speaker-0: And for the other part, we don't have a standardized way of scoring how to feed your threat intelligence. So what's in it for customers? How would they prioritize this? Right? Like, should we look at, I don't know, CISA KV as the primary filter? Should we look at some someone else? Like who who is the who is the ruler in here? Who decides what priority? Right? Personally, it depends on the company by itself, ⁓ for started, right? Like if you are If you are an a ⁓ company in Europe, well look at the Europe kind of ⁓ CISA equ equivalent. I don't know if there is a CISA equivalent in Europe. ⁓ if you're in the US, well maybe CISA is a good idea. ⁓ and for third intelligence, look and discern based on like, hey, are these sectors really attacking my region? For starters, right? Like to see what to do. But I don't know. How how do you feel about this, guys?
speaker-2: I I felt really good about EPSS exploit predictivity something something. ⁓ an acronym, but ⁓ basically trying to predict whether or not a a C B E will be utilized in the near short term. ⁓ so I I had really good looking at ⁓ I felt really good about it look ⁓ like recently up until like probably like three or so months ago. ⁓ mainly just because of the acceleration of AI assisted exploit development. ⁓ I f feel as though the score the EPSS score is not keeping up with the actual reality that we're seeing on the ground right now. And that's kind of unfortunate because I I we were utilizing EPSS for a little while before ⁓ this whole AI revolution thing happened. And I'm gonna keep on calling it that because ⁓ it really ⁓ it did revolutionize ⁓ who how accessible. ⁓ exploit dev and all that type of stuff was, ⁓ or is, I guess, now. So it I don't know. I feel like we're gonna have to have like an EPSS version two here soon, ⁓ that maybe ⁓ is a little bit looser on its ⁓ or maybe they redefine how they're scoring them and saying if they're gonna be actually be exploitable or exploited.
speaker-1: Yeah. Man, latest CVEs. But but yeah, j just to bounce off that, right? If we're using EBSS scores and the Kev, right? The the non-exploited vulnerabilities. I think both of those are too late. By the time those scores are high or they are true, you are already been exposed and possibly exploited by these things. Right. So retroactively, if it goes to Kev That should ramp up your your decision to action it. But it's already almost too late when those numbers get high. When that hits when it hits a high number, chances are you you've been exploited by it or a lot's going on. And don't get me started with with with the known exploited vulnerabilities. If you read their their rules about what they determined to be exploitable, they do count legitimate scan trap, not scanners, but traffic scanning for it that does not truly exploit it. That's a failed exploit attempt, counts as Kev. If have other companies doing the same thing, they toss up honey pots, and now they're saying this is known exploited vulnerability because they're seeing traffic for it. So the truth of what you're seeing no longer resides in one authority and now it's a bunch of them, right? But but yeah, when those two things come together, it's too late. And now you need a new scoring metric. I hate to go back to fingerprinting, but like that's what you gotta do is understand your attack surface to know what your true impact is and what you are truly vulnerable to. And when SharePoint comes out. And you only use SharePoint cloud services, you can ignore that C V E because you know you're not vulnerable to it because it wasn't vulnerable to the two cloud assets. But otherwise, yeah. I I think like Kidrick was saying, it it can't keep up. We had ⁓ what, I think the first half of this year already had like 30,000 CVEs issued in H1 of this year, and that's just like that was the totality of last year. It's just it's just ⁓ astronomical. And we've seen this repeated issue at like disable ASLR and it's exploitable. It's like, yeah, well I'm not I gotta disable it though. And if you if you disable it in production, you probably should be exploited. I'm no no you shouldn't. No you shouldn't. But if you disable the security controls to make it easier for you to implement it, that's not a vulnerability, right? That's a misconfiguration.
speaker-0: Yeah. Which and we go back to another current, right? Like the CWEs and how do you how do you approach those? Because ⁓ similar to ⁓ to to Wasp top ten, right? Like they are not run everything per se, but they are things you should be doing and it's hardening and it's it's a lot. It's it's it's really a lot of work for for the folks out there trying to manage a lot the infrastructure, right?
speaker-1: Yeah.
speaker-2: I think we've gone full circle and we're right back to C BSS scores being like the way that you determine whether or not you should patch because we we were really excited about EPSS and Sisakev and then now now we kinda we we skipped over that time period of of those being useful at this point. I ⁓ yeah unfortunately. Until a new metric comes out, ⁓ C BSS scoring might honestly be the the answer for most corporations to figure out whether or not they should patch, which is Unfortunate because it wasn't a great solution in the first place, but the acceleration that we've seen in the last six months is is too much.
speaker-0: Yeah. Yeah. And I'm kind of quickly going back to ⁓ Richard comment of like, ⁓ if you have SharePoint on the clouds, maybe you shouldn't worry. Which I kind of agree, but at the same time, it's like then how do I prioritize if I have infrastructure? Because current companies have infrastructure everywhere. They have they have like on premise, they have clouds, they have ⁓ SaaS, PaaS, like they have everything, right? Like which one should you be looking at first? Which one is more critical, right? Like how do you define those thin lines between all of your shared infrastructure across all of the different type of infrastructure that you have now.
speaker-1: Yeah. And I think this is where, you know, we get to nerd out. We talk about these levels of the onion, right? So it's like cool, okay. We have on-prem and we have SaaS stuff. The on-prem stuff, I'm I'm I'm risking the hardware and the software together. Whereas or sorry, the hardware, software and data, right? I own all three of those. Lease the software, what do you want to say? The cloud assets, I only own the data, right? The infrastructure is managed by someone else. So, in my opinion, if I am on the cloud stuff and vulnerabilities come out with air, the data loss is my risk. And if I can o if I'm okay with the data that's going to be exposed there, it's not client data, it's benign metrics, I'm doing some kind of tracking. I'm okay. That's not a threat to me. It is a risk. It's going to hit my brand a little bit, but not take me under. Whereas if I own the infrastructure, And I get popped by this thing, and now I have someone living on my land that I can't catch, that's a higher risk. So I always gonna err on a site of on-prem should take priority over any cloud assets because it's just a data loss thing. Yes, we can get in semantics of client data and HIPAA regulations and those kind of things. I'm not saying those aren't important, but losing that data and being able to quantify that versus losing that data, having someone live on my service ⁓ on my server and now moving around laterally in my infrastructure. causing more data loss and more server compromise, I'd say every day of the week, internal systems need priority over over cloud assets.
speaker-2: We well, we've also seen remediation take precedence in the cloud. So Bug Bounty or whatever reports it to the cloud. Cloud patches it literally before they announce it, because they control the software and the patch. They patch it, announce it, and you're good to go, right? And they leave ⁓ all their customers that aren't in the cloud out to just deal with it. we've seen that happen quite a few times where they have patched it in the cloud, released it for on-prem But they released it all at the same time and it's just like, okay, well, all these on prem ones are now up for grabs for somebody to go and get them. And it's that it's it's also a a cost analysis because obviously, you know, some some companies don't want to put things in the cloud. Some people some companies do want to put stuff in the cloud. It's it's really one of those things where maybe it's starting to become more beneficial with how fast ⁓ vulnerabilities are getting created or not created. But exploit found and exploitable, ⁓ that it might be worth moving everything to the cloud just to minimize risk. Yeah. Just like like you get the patch first and ⁓ you're never exploited is kind of a good thing, but I also don't like putting things in the cloud. I personally don't like putting things in the cloud, ⁓ but you know, it is what it is. I'm also not running a company, so
speaker-0: Yeah. Yeah. I think like yeah it's also important, right, like to understand what type of cloak you have. Because there's a certain we go back to like the the misconfiguration, the C D CWE model, right? Like something like Salesforce, for example, you need to do a lot of like fine tuning because otherwise it's like empty and it's it exposes a lot of things. Not in a bad way, but that's how it works, right? Like ⁓ you need to actually do some coding on it to be like
speaker-1: Yeah.
speaker-0: properly secure and whatnot. There is a shared responsibility model for every cloud provider to see what's on your end to result and what's on their end result. Right. Like it it really depends on the type of cloud you are you are dealing with. Right. And for threat for for threat related intelligence it's kind of similar, right? Like ⁓ you normal you don't really want to prioritize those actors that are active right now. Because even today I've seen like companies publishing like hey yeah So so three is traductor, Carbon Act. And it's like, yeah, Carbon Act Fin seven has not been active necessarily for a while, or it has been spun off into other type of tractors, related actors, but not the same original Carbon Act. So you don't really need to protect against those specific C TPs anymore, right? Like maybe it's too old. It's like a two thousand eight act. that that that that went active for for a long time, right? But it's not as it's not as much of a priority as something like ⁓ shiny hunters, right? Like we talk about shiny hunters every week. I think I so so maybe that that's how you need to evaluate. One is the timing is is what will give you precision. And thirteen is like ⁓ I think almost almost every working professional for years in the cybersecurity field has been the ⁓ The pyramid of pain, ⁓ where you talk about like how easy is to block IPs, how easy is to block hashes. But the really challenging part is to look at the TTPs, right? And see how actors really work. I think that's the model we should still follow. I think it's a valid model because there is no wha what is more risky, shiny hunters or IPT forty two? Well, it depends, right? Who you are. Are you are you a government organization? Maybe you need to look at APT. ⁓ for it too, right? Are you and school? Okay, look at China, right? It it it's ⁓ that's why I say all right, I wish we had a system like and it's core I wish I had C VSS for trade actors, honestly. That that'd be it.
speaker-1: Yeah, and and and that raises, you know, ⁓ another bar for we talked earlier about how teams do this. How how do how do teams manage that? How how do teams using even a threat and cell feed know which threat actors I should be watching? Like is that something that that is known in the industry or is that something that you, Sergio, having knowledge of ⁓ T T P and interactive relations is able to explain better.
speaker-0: I believe it's someone that needs to have certain knowledge to do that. Or the company needs to set those intelligence requirements to be able to it's cope that. It's not it's not as as normal or standard as patching C V E's, right? That's a more normal thing in cybersecurity world. But yeah. ⁓ cool. I think this is a this is a great opportunity for us to wrap. ⁓ it was a great
speaker-1: All day.
speaker-0: Yeah, yeah, we we will be talking about this all day. This was a great conversation. ⁓ three things I think I will be walking away with. One is patch window is no longer a window, right? It's like, yeah, you you you have no time anymore. Atomic IUCs and blocking tours. It's not an intelligence program per se. You need to do more, you need to learn TTPs and what behavior the the actors are doing. ⁓ yeah. Scoping for both. Vulnerability and threatening lens is the only thing that will make those problems manageable. Right. so again, thank you, Kendrick, thank you, Richard, for joining us. ⁓ my name is Sergei Villegas. I was your host today. I hope to see you in the next MSS episode. And remember, you can find us in the Pigeonfox Discord, subreddit, ⁓ links will be on the notes. And that's it. See you next time.
