Black Hat Europe 2025: Lessons from the NOC

With the holiday season all wrapped up (pun definitely intended), I finally have time to sit down and digest what we saw in the network traffic at Black Hat Europe 2025 while working alongside the other Network Operations Center (NOC) partners: Arista, Cisco, Jamf, and Palo Alto Networks. As usual, there is a mix of the expected, a dash of the unexpected, and some lessons for newcomers and greybeards alike. Let’s get into it.

The easy stuff.

One of the first things we saw when monitoring the registration web server was, of course, attempts from the outside world to exploit the latest vulnerability in ReactJS (React2Shell). On some level we expected that; it’s widely accepted that once a vulnerability is publicly disclosed, threat actors will immediately begin to reverse engineer it, develop an exploit, and attempt to use it across the internet. React2Shell was disclosed on December 3, and when we started to set things up on December 5, we were already seeing exploitation attempts with a coinminer payload.

Thankfully, the components in the stack did not use vulnerable components, and so the exploitation attempts were unsuccessful. However, they did leave behind a funny artifact; the downloaded payload took a command-line argument which, if I said in the workplace, let’s just say I’d be sent to HR for a conversation about my conduct. It’s interesting sometimes to see what easter eggs attackers drop into their traffic and payloads where they think only a select few would look.

Some things never change; some things never stay the same.

Looking at some of the traffic that contained passwords exposed in cleartext, we were able to rule out the usual suspects: lab environments, capture-the-flag systems, demonstrations, and the like. Among the leftovers, there was something else that warranted inspection: a connection from an internal media network. This meant that whatever was happening, it most likely involved internal systems and processes. Of course, we wanted to make sure that whatever happened there, everyone was aware of the risks and potential consequences. So, we investigated, found the potential user’s system, and sent someone from the NOC to have a conversation with the user to understand what was happening.

It turned out that the user was doing a small-scale test with some signage, using a non-production system, which is a best-case scenario. However, they didn’t realize that the password was being exposed during the test. After discussing it with them, everyone had a plan to move forward: conduct the test, rotate the password, and look for ways to use encryption for the traffic when moving to production.

It surprised me, at first, because I was under the impression that there weren’t going to be any changes with any of the back-end systems, but apparently someone else had other plans. I suppose I could just say “just another day in IT, security, and risk management,” and cynically close the case. However, that would hide the lesson: just when you think you’ve got everything covered, someone will show you what you missed. And if you’re not watching, you’ll miss that, too. So, keep an eye on your network traffic and you’ll likely catch early warning signs for unexpected events that you would otherwise miss.

Apps in the clear… again.

Looking into the network traffic, we’re always interested in cleartext traffic, because people’s privacy, or even safety, can be at risk. In one case during our time at the Black Hat Europe NOC, we located a file synchronization application which was leaking the filenames of all the monitored files on a user’s filesystem. In another case, we found a data loss prevention (DLP) application command and control channel, also in the clear.

Later on, we found a video game whose traffic was in the clear over WebSockets, including in-game chats. The chats we observed were innocuous, game-related conversations, but you can imagine that someone playing with friends might accidentally reveal something sensitive in the perceived privacy. Wouldn’t you assume that the chats were protected by table-stakes traffic encryption of the day?

We kept looking, and we located a realty application that sent all of its traffic in the clear, as well. We could plainly see collections of coordinates that, when mapped, would show the boundary that the user drew on the map when searching for properties. Additionally, it showed all the other criteria in their search. I’m sure these individuals assumed that their traffic was only being shared with the company behind the application, just like the users of the video game.

Applications which send traffic unencrypted to their servers? In 2025? But, surely we figured this out already, haven’t we?! We improved TLS, improved the browsers, and improved awareness. Let’s Encrypt even gives valid certificates away for free … and yet we continued to find new applications whose traffic was not encrypted.

In general, I think we fall into this trap of thinking that because a solution to a problem has been found, the problem is now “solved.” The reality is that the problem is only solved for as long as everyone knows (and uses) the solution. However, language can be imprecise, people can forget things or skip a lesson, old developers retire and new ones come on the scene–any of these things can contribute to lessons being lost or eroded as time progresses. For this reason, I believe we are going to keep seeing new applications sending network traffic unencrypted for a very long time, if not for as long as we have networks and information.

Peep those packets, people.

The antidote is to monitor your network traffic. If you work for a company that develops applications, monitor your hosting. You’ll see whether or not your developers are doing encryption properly, and you’ll see when they change something and it starts leaking information. If you’re an enterprise, monitor the traffic from your campuses; this will enable you to see if users have installed applications that are leaking sensitive information.

In addition, by monitoring your network traffic, you’ll receive significant benefits when investigating alerts. Which brings me to my last point. To gain the full benefits of network monitoring, I recommend looking into onboarding a Network Detection and Response (NDR) solution. It’s one of the technologies that helped us find those in the clear scenarios while threat hunting in the Black Hat NOC. You can learn more about NDR and how it enables SOCs to spot early warning signs of compromise, such as intrusion attempts and lateral movement, in this comprehensive primer.

For more on my previous stints in the Black Hat NOC, check out these blogs.