Blue Team Con 2026

Cyber threat intelligence (CTI) is essentially a decision support function within cybersecurity. As such, CTI that cannot enable, improve, or otherwise facilitate a security action is of questionable value. This is often evaluated in terms of CTI relevance, applicability, or accuracy, but the relationship between CTI and security actions also demands investigation of another metric: timeliness. CTI that arrives too late for the supported decisions is functionally irrelevant.


In this discussion we will explore the implications of a time-oriented view for CTI production, dissemination, and integration into operationally-focused decision making. From this we will identify a key tension at the core of CTI analysis and production: that the SPEED at which CTI is produced and disseminated is often in conflict with the QUALITY or DEPTH of the produced CTI. Organizations cannot have immediate decision support on tactically-relevant timescales while simultaneously having deep context in the current environment. As a result, tradeoffs are necessary to both recognize and navigate in developing a relevant CTI function. Furthermore, evaluating CTI becomes a question of determining audience and customer needs, purpose, and response timelines to appropriately structure CTI support for the entity or specific decision maker in question.


To conclude this discussion, we will examine the possibility of eliminating (or at least reducing) this dilemma through technical means. Particularly future progress in the field of artificial intelligence may allow CTI functions to tap into mechanisms where context or detail and timeliness are no longer in direct conflict with one another, mapping out an effective and meaningful way for AI to support CTI and broader security functions.

AI agents can reason about suspicious files, plan multi-step investigations, and write custom deobfuscation code when standard tools fall short. But generic models produce shallow, unreliable results because they lack practitioner knowledge about which tools to use and when, and access to the tools themselves.
Without domain expertise, an AI agent doesn't know that, for example, capa exit codes follow non-standard conventions, that YARA match counts require context to interpret, or that GetProcAddress appears in virtually every Windows program and is not inherently suspicious. Without tool access, it can only comment on malware but cannot investigate it.
This talk walks through my experience of building an open source MCP server, a standardized interface that connects AI agents to external tools, that bridges both gaps simultaneously. The server connects AI agents to my open source REMnux malware analysis toolkit, encoding practitioner knowledge into tool workflow sequencing and output interpretation. The server runs analysis at three depth levels, and manages context budgets when tool output exceeds approximately reasonable values by automatically switching to summary mode while preserving key findings.
The server also counteracts confirmation bias. Generic AI agents tend to label every API call as suspicious and every string as an indicator of compromise. The server's neutral framing prompts agents to consider benign explanations before concluding malicious intent. This is a critical safeguard when the AI chains dozens of tool calls without human review at each step.
Against real-world samples, the resulting system completed full investigations in about 10 minutes with 25-30 automated tool calls. In one case during my experimentation, the AI agent wrote custom Python to reconstruct a PE from file fragments. In another, it reverse-engineered a proprietary archive format and adapted when initial analysis approaches failed.
The talk covers what worked, what failed, and what surprised me. It addresses the security model required when AI agents have tool access, including prompt injection risks from malicious content in analyzed samples, container isolation as the primary security boundary, and data flow considerations.
Attendees leave with a reproducible pattern for encoding domain expertise into MCP servers, applicable to incident response, cloud forensics, network analysis, or any domain with specialized tools and practitioner workflows.

AI didn't just speed up reconnaissance. It connected dots that were never supposed to connect and most blue teams haven't caught up yet.
 
This talk walks through a single, end-to-end exposure chain so defenders can finally see what they're up against, and know exactly where to break it.
It starts with people. AI-powered OSINT pipelines aggregate and correlate employee data across LinkedIn, GitHub, forums, and breach databases in minutes, building behavioral profiles precise enough to generate hyper-targeted phishing lures at scale. But the exposure doesn't stop at individuals. The same reconnaissance that maps employees also maps the company: infrastructure, misconfigured services, and increasingly API endpoints leaked during LLM deployments. Production AI tools calling internal services, chatbots inadvertently surfacing internal documentation, LLM APIs left exposed during staging, these aren't edge cases, they're patterns blue teams are consistently missing.
 
From there, the path in is shorter than most teams think. Either a well-profiled employee gets phished into opening the door, or an exposed AI-connected service was never meant to be public in the first place. And once an attacker reaches an internal LLM: a security chatbot, an AI-assisted SIEM, an LLM-integrated IR tool, prompt injection becomes the final piece. Your AI doesn't know the difference between a legitimate query and a crafted instruction. Your analyst might not either.
 
We'll demonstrate each stage, then flip the lens entirely covering how defenders can map their AI exposure, harden LLM-integrated tooling, and break the chain before it completes.
 
Attendees will leave with:

• Visibility into how AI-powered recon pivots from employees to exposed infrastructure
• Awareness of LLM deployment patterns that unintentionally surface internal services
• A framework for identifying prompt injection risks in security tooling
• Actionable steps to audit and defend their AI attack surface

Not every incident starts with an alert.

Sometimes it starts with a confident assumption.

In this case, a suspicious email spread internally. The user reported they did not send it, and the client confidently assessed the message as spoofing.

It wasn’t.

Email header analysis revealed the message originated from within the organization (AuthAs: Internal) using legacy SMTP AUTH (AuthMechanism: 04), an authentication pathway that does not enforce MFA. Valid credentials were used, no alerts were generated, and the activity appeared legitimate.

With limited visibility, the investigation required correlating endpoint and infrastructure telemetry. Pivoting on domains associated with file retrieval revealed additional impacted systems beyond those initially reported.

The incident exposed gaps in both detection and control coverage. Mailbox forwarding rules enabled data exfiltration and were managed reactively rather than preventively, while authentication-based detection failed due to legitimate credential use. When questions arose around credential origin, validation had to be guided within the client’s own environment while maintaining privacy and access boundaries.

This talk provides practical guidance for defenders, including how to:

• distinguish spoofed emails from authenticated internal activity using header analysis
• identify authentication pathways where MFA is not enforced
• pivot on DNS and endpoint telemetry to expand incident scope
• detect and reduce risk from mailbox forwarding rules
• validate potential credential exposure within appropriate privacy and access boundaries
• investigate effectively when activity appears legitimate and generates no alerts

Attendees will leave with practical approaches for identifying and responding to attacks that bypass traditional detection by blending into expected behavior.