Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Every SOC analyst and detection engineer has felt it. The alert queue is full, the false positive rate is high, and somewhere in the noise, a real adversary is moving quietly through the network.

Locked Shields 2026 brought together more than 4,000 participants from 41 nations for a live-fire cyber defense exercise built around the kind of pressure SecOps teams know well: Critical systems under attack, incomplete context, multiple tools, and no time to waste. For Corelight, the exercise reinforced a practical lesson: In high-pressure defense, network evidence is not just another data source.

AI adoption inside the enterprise didn't ask for permission. It arrived through browser tabs, code editors, and meeting transcription bots, quietly stitching itself into daily workflows long before security teams could write policy around it. The result is a familiar story with a new villain, a sprawling, unmanaged attack surface that lives in your network traffic but nowhere in your asset inventory. We call it shadow AI, and it's the blind spot you didn't plan for or budget for.

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.

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.

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.