Of course no analogy is ever perfect, but when I talk to friends and family about what I do in the field of IT security, I like to compare it to firefighting and the three key roles that make fighting fires possible. First, there are scientists who conduct research on fire spread and fire-retardant materials. In IT security, the scientists are the academics working on the building blocks that are used to secure systems, such as encryption.
Second, there are the engineers who build the firetrucks and heavy equipment that is used in real-life to put out a fire. In IT security, this corresponds to the engineers from vendors such as Corelight, Arista, Cisco, Jamf, and Palo Alto Networks—all of which were partners in the Network Operations Center (NOC) at Black Hat Europe 2025—developing tools that secure networks.
And, finally, there are the firefighters who go into the heat and take up the actual fight. In IT these are the security operations center (SOC) crews and analysts working relentlessly every day to secure our modern infrastructure. Being a security researcher, I feel at home in the first two roles. But, during Black Hat Europe, I had the honor to join our team of “firefighters” in the Black Hat NOC and feel the heat for real.
Always fascinated by the stories my colleagues brought back from the Black Hat NOC, I was excited to experience it for myself. And, I guess, this is where the above analogy comes full circle. Being told about a fire is way different than feeling the heat yourself. I knew what to expect when going into the NOC: A room with dim lights, booming music, luminous dashboards, popular movie scenes flickering on the walls, and lots of smart, calmly focused people who form a clear contrast to their surroundings.
And then, here I was in the middle of it. Would I see and experience things similar to those told to me by my colleagues? Spoiler alert: yes, all of them!
To begin my work in the NOC, I started digging through alerts. Buried under all of the Black Hat positives (valid but expected alerts due to the educational environment of the conference), I found some classic true positives. For example, I came across an alert for a path traversal attempt on a public webserver. The Zeek® http.log revealed that someone indeed tried to use whatever was available, wget or curl, to download and execute some payload. To my surprise, the source to obtain the payload from was a plain IP. I would have expected that attackers would be more cautious about burning potentially valuable resources like IPs. However, for me, this was great, as I could quickly search the conn.log to see if any sort of communication with that IP took place. The IP also made a perfect piece of intel for future alerting and filtering. And, just like that, by confirming the alert was valid but the attack had been unsuccessful, the first “sparks” were extinguished within just seconds.
Another recurring type of “fire” we see as firefighters is sensitive communication taking place in the clear. During my last shift, Ben Reardon, a true Black Hat veteran, pulled me into an investigation. He found some interesting-looking data that seemed to come from a browser game. Ben dropped me a link and I immediately began analyzing the corresponding PCAP that had some JSON blobs in the clear. He asked me to see if I could spot something like chat conversations. And, of course, Ben had the right instinct. Some of the JSON that was sent back and forth contained “message” fields.
Unfortunately, Wireshark did not display readable characters except some punctuation. I was determined to find out what was actually written there. But, at this point, Ben and I had to break for lunch, as it was our last chance to grab a bite. Hurrying to the already closing buffet, my mind wandered off to how we could break potential custom encryptions. During our quick lunch, I discussed next steps with Ben. Drawing on his experience, he suggested that the solution to this riddle was probably less complex and just encoding related.
Again, he was right. Once we returned from lunch, the answer to a quick AI prompt revealed we were looking at Korean Unicode, and even provided a translation. Turns out that the players of the game were chatting about a rough round, but they finally won their game.
Amidst the fun, probably the most important lesson I learned was that it can also be easy to get “trapped in the fire.” During one of my shifts I started noticing some strange traffic that looked like HTTP, but clearly it was not HTTP. I spotted just a single connection, so I decided not to follow up on this observation and tabled it. It wasn’t until my next shift that I saw various IPs now starting to make these strange connections.
So I went deep down a rabbit hole. From the logs I could see that the communication started with some ASCII characters that represented numbers followed by a binary blob. Again, AI was helpful in the analysis: Whatever we were looking at, it was apparently gzip compressed. However, trying to copy the blob and decompress it failed.
Again I pivoted to a PCAP, used Wireshark to extract the packet content to disk, removed the prepended ASCII-encoded numbers, crossed my fingers, and decompressed the resulting file. It failed again. Only then did I notice that following packets did not have any ASCII numbers prepended, indicating that the binary data might span multiple packets.
And so I tried to merge all of them into a single file and attempted decompression again. Finally, decompressing worked out and I was able to obtain some readable data:
What I discovered appeared to follow web standards. And, again, I was hooked. The data seemed to be related to a train ticket booking. Based on some of the identifiers in the application data, the user seemed to be Italian (language: it-IT). I started trying to “decode” connection after connection, looking for more: a user name, the start or destination of a trip, ticket prices, or any other sensitive information.
Unfortunately, decoding only worked on a fraction of the traffic. While the data revealed some details about the device in use (Device=Pixel\\u209a_cSize=w1080*h2424__v=883.720_os=Android_osv=16_m=Pixel), there was not much more. After spending a lot of time going through the available data, I switched to a different approach and searched for software that uses similar patterns (e.g., similar HTTP-style headers). Eventually, I found a hint in a public database that provided information on tracking and privacy violations in mobile apps. Unfortunately, did my hunt lead to mostly uninteresting information, I was also quite late to the party. While it was great to see how deep one can dig, the lesson I learned here was that what makes a good threat hunter is to know when to stop staring at a seemingly beautiful flame, and go on to look for the next actual fire.
Last but not least, on rare occasions, when the stars align, threat hunters might also literally need to become firefighters. On the morning of the second conference day, the infrastructure couldn’t cope with the energy hunger of our powerful tools anymore and nearly caught fire (see below).
But no worries–the fuses and breakers did their job, so neither the equipment nor threat hunters were harmed. 😉
All in all, I am thankful for the “fire-tested” tools and the amazing NOC team, who guided me through my “Black Hat NOC baptism by fire.” I made it out without any burns (literally and figuratively). Being a part of the NOC was a tremendous experience that provided a lot of inspiration for my future work on Corelight’s “firetrucks.”
If you’re interested in learning more about my colleagues’ experiences within the Black Hat NOC over the years, I recommend checking out our blog. And if you’re looking to elevate your own threat hunting experience, check out our Corelight Threat Hunting Guide.
