Black Hat USA 2026 opened on August 1 at the Mandalay Bay Convention Center in Las Vegas and runs through August 6. The first three days had no new research on stage. They had labs. Four days of Trainings come before Summit Day on August 4 and the Briefings on August 5 and 6.
This part of the agenda usually gets skipped in event coverage. For people running offense and defense every day, it is the most informative part. Briefings show what researchers just discovered. Trainings show what is already being executed on client engagements, with mature tooling, a working lab and a validated playbook. The gap between the two is typically 12 to 24 months.
The 2026 schedule in numbers
The organizers report more than 100 specialized trainings, more than 100 Briefings, more than 80 tool demonstrations at Arsenal, more than 120 sponsored sessions, a Business Hall and Summit Day on August 4. Courses run one, two or four days, at intermediate to advanced level.
The first two days concentrated on vulnerability exploitation, exploit development, EDR evasion, Active Directory, Linux environments, Kubernetes, containers, cloud security, reverse engineering and malware analysis. And, with clear weight, security applied to Artificial Intelligence.
AI moved from conference topic to attack surface
Several trainings that started on day one cover security for AI based applications, protection of autonomous agents, security for LLM environments, secure engineering of AI applications and attacks against generative models.
Translated into the technical vocabulary a security team will find in a Red Team report: direct and indirect prompt injection (LLM01 in the OWASP Top 10 for LLM Applications), insecure output handling (LLM02), excessive agency (LLM06), vector store poisoning in RAG pipelines and abuse of integrations exposed through the Model Context Protocol (MCP).
A concrete scenario
Consider an internal support agent running in production. It reads tickets, queries a knowledge base indexed in a vector database and has access to two tools: an internal contract lookup API and an HTTP client for fetching additional context. A common setup, shipped by a product team in a few weeks.
The attack path:
- The attacker opens an external ticket containing a block of text formatted as a system instruction.
- The agent reads the ticket. The content enters the context with no separation between data and instruction.
- The injected instruction tells the agent to query another customer's contracts and summarize the result.
- The same block asks for the summary to be sent as a parameter in a request to an attacker controlled domain.
- The agent complies. From the application log's point of view, two authorized tool calls were made with the legitimate service credential, during normal business hours.
No memory corruption exploit. No binary on disk. No EDR alert. The controls that fail here are the scope of the agent's credential and the missing boundary between untrusted content and instruction. In assessments we run against production agents, this is the most frequent finding, and the team usually discovers in the report that the agent's token had permissions well beyond what its function required.
The classics still deliver: Active Directory and EDR evasion
The heavy AI presence did not push traditional topics aside. They still take up full lab days in Las Vegas, and they still work against corporate environments.
In Active Directory, the most productive paths remain AD CS abuse (the ESC1 through ESC8 misconfiguration classes, particularly templates allowing an arbitrary subject alternative name), Kerberoasting against service accounts with weak passwords, unconstrained delegation and poorly scoped constrained delegation, plus NTLM authentication coercion relayed to the certificate service. An unprivileged domain user, given one misconfigured template, issues a certificate as domain administrator within minutes. That certificate survives a password reset, which turns the finding into long term persistence.
In EDR evasion, labs work with ntdll unhooking, indirect syscalls, memory obfuscation during sleep, and loading of vulnerable signed drivers. This matters to the Blue Team for a direct reason: detection built only on userland hooking and file signatures has limited coverage against an experienced operator. ETW telemetry, behavioral correlation and active threat hunting are what change the outcome.
Kubernetes, containers and cloud
The modern infrastructure track focused on container escape, excessive RBAC and cloud metadata exposure. Recurring findings in real environments:
- Service account tokens mounted by default into pods that never call the cluster API.
- RBAC with broad verbs, especially pod creation rights in a namespace hosting privileged service accounts.
- Pods using hostPath, hostNetwork or privileged context with no admission policy restricting them.
- Cloud metadata endpoint reachable from inside the pod, enabling node credential capture.
- CI/CD pipelines with broadly scoped OIDC federation, letting a compromised build assume a production role.
Permissive RBAC combined with reachable metadata is the shortest path between a web application deserialization flaw and cluster administrator credentials.
What you can do now
Seven concrete actions with measurable results in a few weeks:
- Inventory the AI agents running in production. Who built them, which credential they use, which tools they can call, which data enters their context.
- Treat LLM output as untrusted input. Validate and sanitize before any downstream component consumes it.
- Reduce agency. A dedicated credential per agent, minimum scope, human approval for actions with external or financial effect.
- Instrument tool calls. Log which tool was invoked, with which parameters, from which context. Without this there is no possible investigation.
- Audit AD CS certificate templates and SPN bearing accounts. In Microsoft environments this is the audit with the best ratio of effort to attack path reduction.
- Set automountServiceAccountToken to false by default, enforce an admission policy blocking privileged context, and require IMDSv2.
- Put the AI scenario in scope for your next offensive exercise. If the agent is in production, it is part of the surface.
How Antisec works these scenarios
Antisec runs Red Team engagements with defined objectives and realistic adversary scenarios, including chains that traverse AI applications, Active Directory and containerized infrastructure. Pentest covers application, API, cloud and internal environments with manual validation of every finding. Our Blue Team practice builds detection and response capability rather than operating a SOC, focusing on telemetry coverage, detection rules tested against real technique and threat hunting. In DevSecOps we work the pipeline: secret handling, admission policy, CI/CD credential scope and dependency validation. The vCISO service connects those results to investment decisions and priority.
The Briefings on August 5 and 6 will present new techniques. The techniques filling the labs in Las Vegas this week are already in use. The useful question for a security team is how their environment responds to them today.
Want to validate this in your environment before someone else does? Talk to Antisec and scope your next exercise.