Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Threat Hunting in the Black Hat NOC is like “finding needles in a needle stack,” said Mark Overholser as we all stared at this massive ice cream that James Pope ordered.

One of the many interesting things we stumble across in the Black Hat NOC (Network Operations Center) is the various applications exhibiting poor security hygiene. Usually it’s something in the clear that makes us chuckle before we move on to more serious matters. Sometimes it’s something more serious that requires letting an attendee know they’re leaking sensitive information.

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.

BitRAT is a potent and versatile Remote Access Trojan (RAT) commonly sold on underground forums. Its popularity stems from a robust feature set and an emphasis on stealth, allowing it to evade detection by hiding command-and-control (C2) communications over seemingly benign protocols. This makes traditional detection methods more challenging. By examining the subtle artifacts it leaves behind, even in encrypted traffic, defenders can expose these elusive threats.

A few years ago, I was part of a team responding to a high-profile security incident. After the incident was resolved, I was given a list of NDR rules to add to my firewalls. The issue was that the rules were not made for Suricata, the IDS I was using in this position at that time, so they generated false positives. With all that extra noise, I made it my goal to eliminate that excess noise.

The first time an MCP (Model Context Protocol) server felt real to me, it wasn't because of a clean demo. It was because of the noise. TL;DR: The harness matters more than the protocol, and the evidence matters more than both. MCP earns its keep when it shortens the path from a good security question to trustworthy evidence, and almost everything interesting about making that work happens in the harness wrapped around the model. In this series, I will cover how to build an MCP for an AI SOC.

At Corelight Labs, our mission is to help organizations stay a step ahead of evolving threats. When our researchers came across Censys' detailed write-up on ScoutC2, a rapidly growing open-source command-and-control (C2) framework favored by threat actors, we knew we needed to bolster community defenses quickly.

It was time to write another book. That’s what I thought when I heard that Corelight wanted to update its 2021 book on network detection and response (NDR). Tamara Crawford, who owned the project, scheduled a meeting with me and asked if I might be interested in helping, depending on who might write the text.

The first time an MCP (Model Context Protocol) server felt real to me, it wasn't because of a clean demo. It was because of the noise. TL;DR: The harness matters more than the protocol, and the evidence matters more than both. MCP earns its keep when it shortens the path from a good security question to trustworthy evidence, and almost everything interesting about making that work happens in the harness wrapped around the model. In this series, I will cover how to build an MCP for an AI SOC.

Adversaries are evolving faster than defenders can respond, and they're weaponizing AI to accelerate their attacks. We’ve seen “living-off-the-land”, lateral movement, and the abuse of legitimate administrator tools enable hackers to hide in plain sight, diluting the effectiveness of traditional detection methods. Meanwhile, defenders are nervously trying to keep up with the accelerating pace of AI-empowered threats hitting them at machine speed.