CyberWire Daily - The CVE countdown clock. [Research Saturday]

Episode Date: August 16, 2025

Bob Rudis, VP Data Science from GreyNoise, is sharing some insights into their work on "Early Warning Signals: When Attacker Behavior Precedes New Vulnerabilities." New research reveals a striking trend: in 80% of cases, spikes in malicious activity against enterprise edge technologies like VPNs and firewalls occurred weeks before related CVEs were disclosed. The report breaks down this “6-week critical window,” highlighting which vendors show the strongest early-warning patterns and offering tactical steps defenders can take when suspicious spikes emerge. These findings reveal how early attacker activity can be transformed into actionable intelligence, enabling defenders to anticipate and neutralize threats before vulnerabilities are publicly disclosed. Complete our annual ⁠⁠⁠audience survey⁠⁠⁠ before August 31. The research can be found here: Early Warning Signals: When Attacker Behavior Precedes New Vulnerabilities Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. Hey, we know you probably hit play to escape your business banking, not think about it. But what if we told you there was a way to skip over the pressures of banking? By matching with the TD Small Business Account Manager, you can get the proactive business banking advice and support your business needs. Ready to press play? Get up to $2,700 when you open Select Small Business Banking products. Yep, that's $2,700 to turn up your business. Visit TD.com slash small business match to learn more. Conditions apply.

Hello everyone and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in our rapidly evolving cyberspace. Thanks for joining us. Within the past two years, we've had this what I will call annex data or gut calls that, wow, we get this weird spike on some piece of usually enterprise-grade edge technology. And then, like, you know, stick in your head that there was a spike. And then, wait, wait, there's a really interesting.

or bad or just new set of CVEs that come out, like really short period of time later that are either bad or do require a patching by folks out there. And like, that's happened time and time again. That's Bob Rudis, VP of Data Science at Grey Noise. The research we're discussing today is titled Early Warning Signals when attacker behavior precedes new vulnerabilities. So earlier this year, we started to say that in our blog posts. Not every blog post, but when there was a decent uptick,

either in just normal scanning activity or for a particular CVE, we were like, huh, that's interesting that we kept tracking six weeks later, roughly between like four to six weeks later, we would see another CVE come out, sometimes a really bad CVE come out as well. And then we decided to just, okay, we're making a claim and we're hedging it like crazy. in the blog posts and like we we need to validate it like we need the science of this thing up so

we took a lot of our data that so we have an entire new sensor fleet we have an entire new architecture so we basically took the entirety of that new architecture which has been up since about September of last year and just combed through all of the events that happened there identified all of the like significant spike outliers I won't do math on here but we put the equations that we used inside the report and took it to took took look at those spikes and then looked at all the related hardware software whatever technology that was associated with that spike so if it was like as an example if it was a um an avanti CVE that we saw a spike on or Avanti scanning we saw a spike on we grabbed all the CVEs for the related avanti gear that that might have been

related to and then we we just looked to see when was the published date of the CVEs after that And we had a couple hundred spike events across like about six or eight technologies, six really well defined, eight, two more loosely defined that like, hey, there's a pattern here between four to six weeks. You're looking at a new CVE coming out. And we're like, this is useful for us to gauge and to look out for. But we also wanted to make a report about it because it's my thing, having been on the defender side and on the vendor side for much, I've been on the defender's set a lot longer.

it's any leg up you can get on knowing when you might have to prepare your defenses for an attacker is just great because it's really expensive to set up extra logging or do a bunch of stuff like that so we want to show some documented evidence show some correlation because we're not

we don't say causation in the report because it would take a lot more data and a lot more time and a lot more evidence to say real causation and then after that it's like here do with this what you will but we're going to try to put this as a thing that we can put in our product

to tell you when there are spike for particular technology. But anybody out there with your own logs, you can do the same thing. Most everybody will see similar activity that we're seeing for some of the opportunistic scanning. And if you have the wherewithal, the bandwidth, the team resources to follow what we did,

you could begin to do this predictive stuff too and maybe buy some time with your budget or with your team to prepare your defenses for what might be coming down the pike. Well, you mentioned that it's typically a six week or so cycle. Can you walk us through that? I mean, what happens when these attackers start probing a previously unknown vulnerability? Yeah, so actually, that's the really cool thing about this. So a lot of people are asking us, like, just from within our data, like, you have

some older vulnerabilities. Like, we have some 20, so we have volumes going all the way back. But for these enterprise technologies, like, there are some 2017 vons in there, some 2020 vons in there. And a lot of folks go, like, our attackers actually being successful with those vulnerabilities. And sure, I guess if they get lucky, they might be able to compromise a host that's on the Internet now if it really hasn't been patched that long. I know patching is not perfect at orgs, but generally speaking, a 2017 volume is not going to be in too many enterprise parameters. So when they're doing this scanning, like our belief was, or like the CVE-based scanning, like actually testing to see if the exploit works against the particular piece of technology.

They're doing that as a cover because what they used to do, like, four or five, so like back when I was at Rapid 7 and I was talking with Morris, like, when he started Gray Noise, we both noticed the pattern of like Opportunistic Scanning going crazy. There were inventory scans happening all the time. And then as both like Rapid and Grey Noise, we started to, you know, tell people about this opportunistic scanning. They kind of went silent for a while and like they use other stealthier techniques to gather inventory what's on the internet. But they still need the geek to keep an inventory. So our assertion has been, well, they're doing this program. against older CVEs, because orgs don't care about the older CVEs. Like, I hear that from customers all the time.

We don't care about old CVEs. So they're getting past their scanning defenses. They're ignoring what that signal is on the wire to just make sure, oh, yeah, there is an Avanti there, or there is a Fortinet there, or there is a sonic wall there, or anything like that. And then they use that inventory to then do, to launch new attacks with a brand new CVE or an Oday or an end day that that might happen down the pike. So our hypothesis was, again, we don't attack people, so we don't know if exactly that's what the attackers are doing.

But it just seems to be that, like, they have a sense that there is a CV coming or they're doing their own exploit creation and they're testing against old TVs to get under the wire, like to get under the radar of organizations. And then they use that to have a more precise inventory because they really want to be able to get as many hosts as possible. Well, how often did a spike in malicious activity lead to an action? CVE and what's that time frame look like? Yeah, so if you look at the report and I'm just going to scroll real quick,

just like I could give you some more like some more concrete information. Yeah. So within there, what it looks, if you look at it and this is like page for folks that are listening to the report in front of page six of the report, there's a, it shows kind of the sequence of spike to CVE and, you know, roughly on there, what you can see is there's 200-ish events. I like to round because people don't like precise numbers. And those 200 events are indicative of that within six-week time frame.

And, you know, it's a handful of CVEs, so it's like I think it's under 30 CVEs total for the whole thing. So across those technologies, there's at least one to three CVEs that came within that six-week time period that basically means the attackers were doing that scanning and knowing in advance from what we can tell that this new CVE was coming or that they were the ones that were creating the exploit that created the CVEE. And what kind of technologies show the most reliable warning signals? Yeah, so that's a really important question too for orgs. So we looked at every single technology that we have in the edge category. And what we first did is we said, okay, we need to see, you know,

what do the patterns of scanning and attacking look like for these technologies? So I'll give you one that we didn't put in the report and that we didn't analyze. It's like D-Link. And actually, I'll throw lynxys in there too. So D-Link and LinkSys are extremely noisy technologies from like an attacker perspective. Like they're doing constant probing. It's almost like a heartbeat. So in the report, I think we actually use that terminology.

We said, look, if there's a heartbeat, if it looks like some, it looks like attackers are just going after a particular technology a whole lot. or if there are just scads of CVEs so that we couldn't find any signal in that noise, we ignored that. So DLink and Linksys and a bunch of other ones that fall into that category, we basically threw away because there was no real spike activity, and there was just too much of noise to say that there's signal here, which ended up leaving us with enterprise technologies, which I was actually surprised at.

I actually thought maybe there wouldn't, I didn't actually realize there was that many CVEs for DLink or lynxist or those things. I tracked this stuff, but my gosh, there's a lot of vulnerabilities. these on this kit. And so for these enterprise technologies, we ended up looking across all of the edge enterprise technologies that are out there.

And we didn't deliberately land on, you know, Cisco, Fortnite, Juniper, Palo. Like, I'll list the ones that have more signal in a second. Like, we didn't deliberately pick those. They just happened to be the ones that bubbled up from the signal analysis that we did. So Cisco kit has a, like, I would say that it's an,

80% confident signal that you're going to see that pattern happen on there. But for Fortinet and for Juniper and for Palo Alto and for Sonic Wall and Avanti, those ones show a very high signal with this spike to

CVE within six weeks. One that I really, I like, I hate to say it this way because I just don't like Cedric's, but I was hoping we would see it very concretely with Cedricz. And we just didn't see that firm of a signal with Cedric's. And, And a technology that I used to really not like a long time ago,

but micro-tick is getting a little bit better in their safety protocols. I thought we'd see a lot more signal in micro-tick, but honestly, attackers aren't even going after micro-tick as often as they used to before. So we really didn't see a whole lot of signal there as well, too. So, again, it's the big players, Avanti, Fortinet, Juniper, and Palo, like the strongest signal, very high correlation. Cisco, about 80% correlation.

And then Citrix and Microtick, not a great correlation. I wouldn't be using their signal if I was a defender and I had to spin up more defences or spin up more logging. I wouldn't choose to do that if I saw a spike on those. We'll be right back.

I'm Ben Yellen, co-host of the caveat podcast. Each Thursday, we sit down and talk about the biggest legal and policy developments affecting technology that are shaping our world, whether it be sitting down

with experts or government, officials or breaking down the latest political developments, we talk about the stories that will have tangible impacts on businesses and people around the world. If you are looking to stay informed on what is happening and how it can impact you, make sure to listen to the caveat podcast. Can you help me understand the why here? Why are these attackers behaving in detectable ways weeks before a CVE is published? Well, so again, like, it is detectable if you know what to look for. And like, again, most organizations are so overwhelmed with data hitting their perimeter,

whether it's legitimate stuff from applications or whatever they host, or attackers, you know, or scanners. Like, there's just so much of volume hitting an organization of perimeter. They have to throw away a bunch of data that they don't care about. So they will ignore, you know, that. normal probes, like lightweight probes, or hits against CVEs that they know they've hatched, like they would just ignore that activity because they feel like they've been able to defend against it. And honestly, they have to deal with all sorts of other things right now that they just can't

prioritize that. And so attackers, it also looks like a couple of things are happening with attackers. One, they either are the ones creating the exploits that they know they want to deploy or they're following bug bounty hunters or other research teams or even work on at a vendor. I think if people just take a look a couple weeks ago, I believe it was like it was revealed that Microsoft sort of revealed to Chinese attackers that there were volumes in SharePoint, which caused the SharePoint problem like, you know, just a couple weeks ago.

So like vendors, you know, aren't necessarily as tight with their information as they should be. Bug Bounty hunters aren't either. The bug bounty platforms might not be. Or the attackers are just, you know, creating their own exploits for an eventual O'Day, which then will get a CVE almost immediately after the vendors or the researchers figure out what to do.

And the scanning that they do, do, it's really for, it's an augmentation reason, or they don't have resources. And like, I'll explain that. I'll explain what I mean by that. So we saw starting around three years ago at Grey Noise that the, what we used to call inventory scans, like basically you could count on like within this couple days a month, you'd see this botnet do an inventory scan of the internet for this technology. And after enough of, like enough orgs like Gray Noise started reporting on that and helping

organization defend against that, that inventory. scanning activity went substantially down. And what they do instead is they will take any one of them, like there's so many internet scanning companies out there right now. So I don't want to mention any one of them because it's not their fault that attackers do this. But you take any one of the benign, good guy internet scanners out there, they do that scanning for the organization so the organizations can know what's on

their perimeter. Anybody can subscribe and get an account though. So if you want to get one of those providers, you have Chaudan census or whatever and just say, hey, show me where all the fortinets are. It'll do that because that's what the whole purpose of that database is.

And so, like, most of the time, the, like, the, and so we divide attackers into, like, three categories, A-listers, B-listers and C-listers. So the A-listers are like nation-states and the C-listers are like the people that just scrape the bottom of the barrel

rent some time on the Mariah botnet and do what they will out there. So the A-lister stopped doing inventory scans. They just completely stopped doing them. But every so often, they do need to, like, augment the inventory that they have with census, with something a little more recent or a census showdown, whoever, I'm not, again, I'm not picking any one of them because it's not their fault. And they'll use that data for targeted scans, but if they really want to have their own inventory and update it and have, like,

a really crisp, like immediate thing so that they know they can use it within a certain period of time, they need to do their own scans. And they can't do what they used to do, which was like just do random scans for technology or fingerprinting or whatever. So by launching a CVE-based exploit or attempting to do so, making it look like they're idiots that they don't know what they're doing

because why would you try to like do that against that piece of technology, it gets under the radar of everybody and that gives them a really fresh, crisp inventory. Now, there's also a secondary thing where if an org hasn't patched a 2020 CVE

or a 22 CVE, they can compromise that host as well too. So like, they get two, two potential bangs for their buck. They know that there's a piece of technology that they want there, and they may have been able to compromise it

at the same time. So, like, they get that win, and they don't do them as regularly. So these spikes don't happen on a regular time period. If you look, again, back on page six of the report, you know, each different graph, there has a different time frame.

And, like, some of them span between, you know, January of this year to July of this year. Some go back to December or September of last year to now, some are just more recent. So they don't do the inventory scans with a regularity like they used to do, they do these bursts to try to get under the radar

and then use that data later on for when they want to have, when they want to, when they know a CV is going to happen or they create an exploit that causes a CV to happen. Well, what are your recommendations then for defenders? What should they do when they spot one of these spikes? Yeah, so what if I get, if I were back, I thankfully am not in a system position and I'm not,

I don't have to do what real, but people would have real work for a living. have to do, which is, like, defend an org and protect orgs from from their stuff because it's really hard. The one thing that, like, I do know is, like, if you need to do, like, extra logging, like, either from a system log perspective or, let's say that you want to capture a full PCAP or even partial sampled net flow, doing that for, like, all year across all sorts of devices and technologies is you just can't, like, even the Fortune 100 can't do that for all those kinds of technologies that are out there. So if you see a spike

happen against one of these older CVEs or just like one of the scanners, because a couple of our scanner tags, just the vanilla scanner tags also saw some spikes. If you see that in your logs and that you should be able to take time for, get that into some big data system and be able to do spike

detection. Like we didn't do, this wasn't rocket science. This was basic just core data science statistics that we did on here. It is, you can do that. You'll get that notification and that should be a signal that you should flip on, maybe some net flow logging, flip on full PCAPs at least part of the time for different days or get full system logging

going into your expensive Splunk data warehouse or whatever. So you have that to look for to see what might be coming against your environment down the road. And that six-week cutoff is actually a pretty decent amount of time to get, though, that logging set up, to get that extra data capture set up, and be watching for what happens with that extra data capture. And I think if orgs could do that, they would be in a better position to see, new weird activity happening against them or if a CVE comes out within six weeks they can also

plan with our operations team to make sure hey can we make sure we patched that if a CVE comes out within six weeks can we make sure that there's the emergency patch procedures ready so we can get those patches in and therefore not let whatever those brand new like one end day attacks that are going to happen against those CVE be successful against that organization so we wrote it really for those two things in mind to give you the ability to like prepare your defenses and logs and just watch for what's happening a lot closer so you don't waste a lot of money to do that in resources. Or on the flip side, coordinate with all your internal teams that you have to.

Because taking down a Cisco firewall or router, taking down a Fortnite appliance, I can get on the list, you are taking that down down. You might not have an H.A. set up, a high availability setup. So if you take that down, it causes real downtime for real people. It's a real business thing. But if you can coordinate it ahead of time or know in advance, you have to watch for these things so you can block IPs on your own if you want to do that or, or, or, or, or, you can coordinate it ahead of time. or know in advance you have to watch for these things so you can block IPs on your own if you want to do that or watch

what we have over here. That gives you real power to maybe not be in that first round of attacks that attackers are doing. And again, it does require some resources. It requires a different frame of mind for the teams. You might actually have to like, you know, get some folks that know how to do like the logging

so you can do the time series analysis. But honestly, it's a small investment for them to do that to potentially save themselves for like a really a bad attack because it just seems lately that like CBEs come out and the or an attacker will like launch an O day a CDV will happen right after that and everyone's taken by surprise and like they just don't have any time to react. We were hoping with this analysis to give them some tools that they can use to be a bit more prepared if you have the ability and time

and resources to kind of do that kind of analysis. What about false positives? I mean, were there any surprises where a spike didn't result in a new CVE down the line? That's a wonderful question. And we chose that I put the graph in the report because it was a lot more complex. So there were ones that fell outside of that window, but it was like 20, it was like in 20% range of the spikes

that fell outside of the six-week window and didn't fit into there. And they weren't with the technologies that we show in their report. What we chose to put in their report where the technologies were, we saw these spikes, there was the propensity of them there.

And we included, like I said, the Citrix one and the microchick one to show, yeah, like they, And even Cisco, it's only 80% of a signal. So we did show that. So you could see, yeah, like, we, we aren't saying that this is a complete predictor. There isn't, like, solid 100% correlation across all technologies for this. But there's enough of a correlation for it for certain types of technologies that you can use this to your advantage to be prepared.

Like, there's actually one graph in the report. I want to see it's, yeah. So it's on page 10 of the report or so page 9 of the report. And there's like an area graph above. what looks like something shooting like little dots out. There's a lot of dots after this. There's not a lot of dots

after the six week line, but there are dots after the six week line, which means that that spike to CVE correlation wasn't within that six week time frame. And that's really important for folks to realize, look at this, choose to set up your defenses if you want to this way, but there is a huge correlation

for, again, a good number of technologies that makes a lot of sense for people to do that. so what are your recommendations for for folks who want to get started to taking a look at this what's what's the best way to to check this out so most folks do you have some type of detection capabilities within their perimeter i know some of the organizations that just can't afford a whole lot of stuff don't have that but the ones that that that if you can afford a decent size fortinet or a decent size avante or cisco like you do have some some capital

expense money like in your security budget uh if they're ignoring older vulnerabilities because you believe you patch them all, I guess the first thing I would say is at least take a look at the CVEs that we noted inside ours, it's our report for those, and have your detections log the hits to those CVEs and then basically take those things, put them in some kind of, it doesn't need to be like an gigantic Oracle database. You can get SQLite and like they just shove this data into like a small database and just regularly run checks against the spikes with, again, the equations that we provided to you. It literally is that simple, is like, hey, log these events, check it for the spike events,

and then you do your own comparisons. And what's been really interesting about that, actually, I was going to say that earlier. So I had no idea how this was going to, like, we don't pre-release reports to everybody. We just release it to everybody at the same time. And I got so many responses from other researchers and other defenders. So, like, there was, I, we had one person tell us, yeah, I was in my DFR community Slack. I have no idea which one it was. And there we go, like, we all had this gut call that, like, that we, this felt like it was happening too, but none of us could justify the time to go do that log collection or event collection, the correlation and do that.

And a whole bunch of them are now going to go do that with their own stuff because, again, this is hitting your perimeter just like it's hitting our stuff. So, like I would say, there is definitely value there. A lot of other folks have said, wow, yeah, this tracks. Like, we felt this too, and I'm glad someone did some data behind it. And my hope is a lot more folks do take that time and kind of double-check our work. Like, basically, like, see what, you know, do what we have done against your stuff. If you can go back in time and do that, if you were logging stuff before, that'd be amazing, too. Because I'd like to know that the correlation, the signal is even stronger than we've already shown for the data that we have.

And we're going to be continuing to update this and revisit it over time. So we can tell people, yeah, like this signal is. there. The correlation is still there. Although, by doing what we've done, we may have told the attackers that we know what they're doing and they may stop what they're doing. I have no idea. It's one of those things. The minute you tell somebody that, like, you see this, they might stop doing what. It's really, really frustrating when they do that. Yeah. It's frustrating. At the risk of being cute, you know, it reminds me of, I think it was an old Bob Seeger lyric. You know, I saw the lightning and waited on the thunder. You know, the spikes are the lightning and the

CVE is the thunder. Wow, I wish you could Wow, that would have been amazing for the report. That would have been so amazing. Well, feel free to use it if you ever do a, you know, a TED talk on it or something like that, right? Oh, man. Oh, man. I don't know.

Well, Bob, I think I have everything I need for our story here. Is there anything I missed, anything I haven't asked you that you think it's important to share? I think maybe the one thing I would just say is like that I know organizations had to be focused on. on the core defender operations that they have to go do. But they're sitting on a treasure trove of data that if they could allocate just some time to go ask questions of their own data, like, I work for a vendor. So like this vendor is not going to be happy. I say, well, actually, I think they'll be fine with it.

You have your own treasure trove of data. And it's like the tools to do data science, just basic stuff on that data, exist like all over. They're all free too. like the rest of your already are free. And if you can justify or like find some way to justify carving out some time to just start asking questions of your data, like for all

the folks that are listening to this that had that same gut call, you thought, yeah, this feels like this is what happens. And you've had that thought for the same couple of years that we've had, go talk to your boss and say, hey, can we carve out like three hours a week to go do this kind of stuff on our own data? And I think you're all going to be surprised at what you'll find if you could actually go do that.

And you know, not relying on anybody else accept yourself to see that kind of information. I think you can develop some pretty powerful in-house techniques and in-house tools to repeat this and find more and new and novel stuff that people aren't looking for right now. It also strikes me that, you know, in this age of AI and automation, that there is still a really important place for that gut feeling to chase down that gut feeling. Oh, 100%. So the one thing that's really important is you're always supposed to start any type of analysis or process or. whatever like in for when doing this kind of work with a hypothesis and the only way you're going to get a hypothesis is if you're thinking about stuff and generally with generally it's

speaking insecurity everything starts with a gut call because you just you have this like spidey sense that this is happening and this is happening I need to now somehow determine whether my hypothesis is true and most people just don't have the time to to actually act upon that and again I would just I would just urge folks if you have that gut call find some way to get someone to give you the time because the resources are pretty much free and go do that because I think you'll find a lot more than you're finding right now. Our thanks to Bob Rudis from Grey Noise for joining us.

The research is titled Early Warning Signals when attacker behavior precedes new vulnerabilities. We'll have a link in the show notes. And that's Research Saturday, brought to you by N2K Cyberwire, we'd love to hear from you. We're conducting our annual audience survey to learn more about our listeners.

We're collecting your insights through the end of August. There's a link in the show notes. Please do check it out. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher,

and I'm Dave Bittner. Thanks for listening. We'll see you back here next time. Thank you. Thank you. Thank you. POMAYOR.