Ten Black Hat NOCs and counting: Corelight sees it all

Whenever I come back from a Black Hat NOC, people always ask the same question: “So, what did you see?!” They understand how unique it is to have access to the detailed logs generated by an NDR overseeing the network traffic of a conference with thousands of attendees. There is always something to see. There are always stories that come out of the packets; those stories evolve into patterns, and the patterns offer the gift of lessons. Corelight has had the privilege of partnering with the Black Hat Network Operations Center (NOC) for ten Black Hat conferences. The stories keep coming, and so do the lessons.

This time, three lessons stood out: People make mistakes, trust but verify, and it can happen to anyone.

Lesson, the first: People make mistakes

One thing we are routinely surprised to see in the network traffic is cleartext or easily decoded sensitive information. Not because it’s novel, but because by now you would expect the technology industry to have learned the lesson: encrypting all network traffic should be routine. The internet is middle-aged. The DEF CON Wall of Sheep is old enough to drink, and almost old enough to rent a car without ridiculous insurance premiums. You would think that by now, this lesson would be ingrained in our collective consciousness.

Yet, at every conference, we still see multitudes of things in the clear that shouldn’t be in the clear: phone calls and translation apps, EDR command channels, corporate chats. The hits just keep coming. I can’t look away!

One thing we continue to do is use an agent to automatically sift through HTTP traffic and flag items that have more interesting characteristics.

At this conference, the agent flagged communications that appeared to contain “user account identifiers.” When an analyst dug in to confirm, yes, the request did indeed contain identifiers.

The rough translation of the appname value was “Meeting Record Assistant.” Uh oh. This is where many threat hunters, incident responders, or network administrators would close the case, make response recommendations, and move on. However, that extra bit of curiosity can often pay off. Don’t stop until you have decided you have no more questions to ask, and no more answers to uncover.

The analyst on this case asked the question: "What else does that device talk to over cleartext HTTP?” That curiosity paid off. In another session, the device initiated a request to a different domain, but using the same generic user-agent string. That domain is tied to a Chinese app development company (according to their website), and the response to that request contained a Tencent application API key.

Yowza! That’s certainly not what you want to see. Application credentials like that should be kept secret, of course. Without attempting to use those credentials, it’s hard to know the full extent of the privilege they provide, but even if they only grant access to just a back-end for this application, it’s still probably more than the developers intended to expose.

The lesson: I’ve said it before, and I’ll say it again, people make mistakes. It’s a thing, and that’s okay. We need to acknowledge it and have safeguards in place to catch those mistakes, and establish processes for when they happen. Here, a developer made a mistake, and NDR caught it. Had the development team inspected the network traffic of their own app before release, they may have caught it earlier. With NDR, you can also catch mistakes that your own developers, users, administrators, and AI agents make, and take action to correct for those mistakes as soon as possible.

Lesson, the second: Trust but verify

If you’ve read past blogs from our time in the Black Hat NOC, you know that passwords often show up in the network traffic. I’ve accepted it as a fact of life. Perhaps I’m jaded. Oh, well.

When a password is identified in the network traffic, I no longer ask the incredulous question, “How did that happen?” Instead, I ask other more useful questions

• “What is that system?”
• “Who is that user?”
• “What was that password meant to protect?”
• “How serious does this seem given the context?”

I have found it more productive to get to the root of the situation rather than to jump straight to anger or embarrassment.

Sometimes, though, a password is just too striking not to stop and appreciate it.

This password is quite the beauty. It has mixed case, punctuation, and special characters. It’s long, and even perhaps a bit melancholic, a misheard lyric from Wham!’s Careless Whisper. This is no throwaway password; it’s someone’s soul on display.

Okay, now we can ask: “But why is their soul on display? It’s 2026, surely that password should have been protected by a veil of encryption?” Fine, I’ll bite, but only because someone’s soul is on the line here.

In this circumstance, we do what we always do: ask questions. What other devices are connecting to it? Are there any domains we can associate with the destination IPs based on the HTTP headers, TLS SNIs, and DNS requests from the client(s)? Are there any other identifiers in the traffic?

I know I keep saying this, and you’re probably getting tired of it, but: Uh oh.

The fact that this was a VPN is significant. VPNs carry trust. A user trusted that application, and the application violated that trust (we’ll assume that was an accident).

The lesson: Trust…but verify! You never know when someone else will make a mistake with technology that can have spillover effects for you and your users.

Bonus lesson: Maybe consider having distinct passwords for each of the applications in your life, so that when one of them leaks inadvertently through no fault of your own, it won’t cause issues for others. Password managers make that easier than ever.

Bonus bonus lesson: If this was your password, maybe consider rotating it. I’m sorry for your loss, not only of this particular password, but also of the spark that drew you to dance in the first place. I hope you get your groove back, one day.

Lesson, the third: It can happen to anyone

Infections: Everyone gets them. This is why, as a society, we have antibiotics. Wait, no, I meant computer infections!

That’s right, infected devices are something that comes up occasionally at Black Hat. There are thousands of people and devices on the network, so even if the odds that any single device is infected are low, the sheer number of devices means it’s still pretty common to see evidence of at least one or two infected devices at each conference. We’ve seen an attendee in a malware class that had malware on their own laptop (not intentional, and not an accidental self-infection of something they were analyzing). We’ve seen corporate devices carrying latent malware that the installed anti-malware solution had missed. We’ve even seen a presenter connect to the network at the start of a talk, only for us to catch malware on their laptop almost immediately. (And yes, they already had an EDR, too.)

This time, there is a new twist. It started with a device connecting to the network and triggering IDS alerts for two distinct Remote Access Trojans (RATs). Generally speaking, I’m a skeptic. If I get a notice for a RAT, I say “Prove it” and analyze it six ways from Sunday until I’m convinced it’s not an accidental misfire of a rule. For an example of why this skepticism is necessary, check out my analysis of a hit for a TripleNine RAT from Black Hat USA 2023.

However, in my experience, if a host is triggering detections for two distinct infections, that’s pretty much never a good sign.

Corelight’s Agentic Triage, the expert SOC analyst AI built into Corelight Investigator, also analyzed the event, and came to a similar conclusion: “Not good, my dude.” Yes, I paraphrased a bit.

When something like this happens, we in the NOC want to figure out who it is so we can let them know of the danger. In some cases, we can figure out the exact individual through clues in the network traffic–first names in usernames or device names, email addresses in TLS certificates, things like that. Sometimes we can only infer an organizational affiliation based on domains that the user’s device accesses.

NOC staff have taken these methodologies and operationalized them using an AI agent that we collectively call The Profiler. It uses those same tools to look at the Corelight logs, then makes its best guess about some of the characteristics of the individual, and returns a few paragraphs of analysis. Okay, you’re right, it returns several pages of analysis–that’s just AI for you. It’s fine, they’ll figure out a way to make it more manageable later.

In this circumstance, The Profiler performed all the lookups, munched on the results, and spit out the conclusion: “...likely a security/tech journalist covering Black Hat for [REDACTED].”

You might think that’s terrible news, and you’re right! The silver lining, though: The pool of potential individuals just shrank by a few orders of magnitude. A couple of Google searches for articles about Black Hat later, and that pool shrank even further. Once the Registration team confirmed that our candidate was registered for the conference and had checked in, we knew we were on the right track. All the NOC needed to do was make contact.

So, the NOC managers, Bart Stump and Neil “Grifter” Wyler, reached out internally to the team that manages the press relationships, and passed along the message that this specific journalist really, really needed to stop by the NOC so we could share some distressing news. In short order, the affected individual stopped by. NOC staff walked them through the situation and the evidence, and offered some suggestions about what to do next, namely: Shut that device off and talk to your IT and Security teams immediately.

The lesson: It can happen to any of us. We’re all using vulnerable software and devices, and we should all be keeping an eye out for potential threats. We keep a vigilant eye out for this in the Black Hat NOC, and sometimes people leave with knowledge that they were at risk without ever realizing it.

Conclusion

Black Hat Asia 2026 was a striking success, in no small part due to the hard work and dedication of all of the partners involved: Arista Networks, Cisco, Corelight, Jamf, MyRepublic, and Palo Alto Networks! Remember, networks can contain all kinds of interesting things, and if you just look at the traffic, there’s no telling what you might find! We’ll see you at Black Hat USA!

For more on how defenders can use network evidence to investigate threats, validate alerts, and uncover activity other tools miss, see the Corelight Threat Hunting Guide.