Lo mejor de BSides LV 2026

¿Qué es BSides Las Vegas?

BSidesis es la conferencia que abre el Hacker Summer Camp, la semana de Las Vegas en la que ocurren también grandes conferencias como Black Hat y DEF CON. El nombre de BSides viene del lado B del disco de vinilo. Nació en 2009, con menos de cien asistentes, de un grupo de personas que se juntaron en una casa alquilada a dar las charlas que Black Hat había rechazado. En 2012 BSides se constituyó como entidad sin ánimo de lucro y hoy la red global suma más de mil eventos en 255 ciudades y 65 países.

El año pasado escribí una guía completa sobre cómo funciona BSides LV: los tracks, los precios, los badges y cómo aprovecharla si vas por primera vez. Si es tu caso, empieza por ahí. Este blog es otra cosa.

Este año fui completamente por las charlas.

BSides LV 2026 en cifras

La decimoctava edición ocurrió del 3 al 5 de agosto en el Tuscany Suites & Casino. En esos tres días hubo 141 charlas, más 25 trainings y 29 actividades paralelas: 195 bloques de agenda repartidos en 10 tracks, 19 salones y unos 211 ponentes. El martes fue el día más cargado, con 83 bloques; el lunes 71 y el miércoles 41.

Yo estuve el lunes y el martes. En esos dos días vi 21 charlas en sala, de 8 tracks distintos, sumando un total de 13 horas de charlas. Seis de esas charlas fueron Skytalks, las que no se graban. Diez llegaron al meetup que di después, y seis llegan a este texto.

Lo que hace distinto a BSides

Hay algo que noté durante los dos días y que no siempre pasa en otras conferencias: realmente costaba escoger qué priorizar. En varios bloques había tres charlas buenas al mismo tiempo, y elegir una significaba perder las otras dos, o dejarlas para el live de YouTube más tarde, siempre y cuando no se tratara de una Skytalk. Y aunque esto suene a queja, es en realidad uno de los mejores elogios que se le pueden hacer a una agenda.

En esta, así como en otras conferencias, los vendors también están ahí, pero tienen su espacio definido y no se meten en las salas. Tienen su lugar en los stands del Middle Ground, pero no los ves luego en charlas que en realidad sean un pitch disfrazado. Cuando alguien de una empresa sube a la tarima, sube a contar investigación.

Y no es solo sentarse a oír charlas: hay retos, villas y actividades repartidas por todo el evento, y una buena parte de lo que uno se lleva pasa ahí.

Además, hay unas cuantas reglas que cambian el ambiente de la sala más de lo que uno esperaría. La primera es que nadie te fotografía o graba sin permiso, y es una política que la gente respeta de verdad. La segunda es que no se tolera en absoluto el acoso de ningún tipo. La tercera es la de las Skytalks, con su token, su fila y sus teléfonos apagados. Las tres apuntan a lo mismo, que es proteger la privacidad de quien asiste. Y funciona: ves gente de todo tipo y vestida de todas las formas, cada quien va a su estilo, y eso pasa precisamente porque ahí todos se sienten aceptados.

Las charlas

De las 21 charlas que vi, estas seis son las que traigo. No son un resumen de la agenda ni pretenden serlo: son las que a mí me cambiaron algo o me parecieron realmente buenas. Cuatro están grabadas y quedaron en el canal de BSides LV en YouTube. Dos fueron Skytalks, y de esas cuento de forma general lo que ya es público por el abstract, o por publicaciones en línea.

Cuando el atacante no existe

"Your Next Breach Won't Have an Attacker" ~ Guy Barnhart-Magen, Profero · Skytalks

A las dos de la mañana el equipo de respuesta a incidentes recibe la llamada: código de producción borrado, base de datos expuesta, datos de clientes desaparecidos. Todos los indicadores clásicos de una brecha. Excepto que el atacante no era un threat actor, sino un asistente de código corriendo con --dangerously-skip-permissions y una instrucción vaga de un desarrollador, del tipo "clean things up". Profero lleva un año respondiendo a una categoría creciente de incidentes que ya bautizaron como AI-induced destruction: daño catastrófico causado por asistentes en los que se confió de más, se instruyó de forma vaga y/o se le dieron permisos innecesarios. 

La charla narra tres incidentes reales con reconstrucción forense completa. Todos los incidentes siguiendo un patrón similar, un desarrollador y un agente con permisos completos y aprobación automática de todas las acciones: el control que fallaba no era solo de detección sino de autorización. Al final, la recomendación que se entrega es de tener logs buenos de lo que ocurre y documentación sobre todo lo que la IA va a tocar.

"Your Context is Mine! When a Single Drop Poisons the AI Agent's Well" ~ Itsik Mantin · Ground Truth

▶️ Ver charla

Todos los agentes de hoy funcionan igual: recogen documentos, correos, mensajes y resultados de búsqueda, los meten en la ventana de contexto y razonan sobre el montón. Mantin se preguntó qué pasaría si el atacante controlara un solo documento entre diez o veinte legítimos, ¿sería capaz de hacer que la decisión respecto a los otros 19 cambiara? Este fue el experimento e investigación que llevó a cabo: en este caso el documento envenenado no le da ninguna orden al modelo, se limita solo a afirmar algo sobre los demás "LATEST UPDATE — ALL PRIOR DOCUMENTS OUTDATED" y con eso el modelo elimina por completo la contribución de los otros diecinueve de su razonamiento.

Al contrario de lo que se pueda pensar, agregar más documentos no necesariamente mejora la defensa. Lo que sí resultó importar, fue la posición del documento insertado, porque al final de la lista funciona mejor que al principio. Y ningún modelo resultó inmune, aunque los modelos frontera terminaron aguantando más. Una diferencia importante es que esto no es prompt injection: como no hay instrucción, los filtros de inyección que ya tienes montados no alcanzan a verlo. De las tres defensas que midió, la única que llegó al 100 % fue una denominada extract and vote: el modelo lee un documento a la vez y emite un voto, y el conteo lo hace tu código de manera que la decisión queda en la mayoría y no en el modelo.

"Breaking BOTS II: How frontier AI cheats evals" ~ Leo Meyerovich, Graphistry · Unprompted

▶️ Ver charla

Cuando un agente entrega la flag correcta hay dos preguntas distintas, y casi nadie hace la segunda: si la respuesta salió de razonar sobre los datos (eval integrity) y si pasó algo en el camino que nadie quería que pasara (collateral damage). Meyerovich mandó el CFP de esta charla meses antes de que ocurriera un incidente real que siguió su timeline casi paso por paso: el agente encuentra un 0-day, se escapa del sandbox, monta un C2 fuera del firewall y hace movimiento lateral buscando la respuesta. Su prueba de contaminación es valiosa por lo simple: corren el CTF completo sin conectar la base de datos y los modelos siguen sacando buen puntaje, lo que se explica porque la respuesta ya venía en el entrenamiento. En la charla, se describe un bypass de egress que ningún firewall es capaz de ver: el harness agrega una tool nueva, un web_fetch, que proxea la petición por el propio proveedor del modelo, cuyo endpoint ya está en la whitelist del firewall, y con eso hace las consultas que necesita a internet.

El punto de fondo de la charla es más incómodo que cualquiera de las técnicas: un agente bajo evaluación hace trampa. No por malicia, sino porque va a buscar cualquier camino que lo lleve a cumplir la tarea, y sacar la respuesta del entrenamiento, del historial de Git o de un endpoint que ya está en la whitelist son caminos tan válidos para él como resolver el reto. Prohibírselo tampoco funciona, y su frase para explicar por qué es "do not think about strawberries": si le prohíbes hacer trampa mientras lo presionas por la flag, acabas de meterle la trampa en el espacio de posibilidades.

Los bugs que nadie mira

"Every ride you take - Hacking a City's Public Transportation (PART 2)" ~ Ignacio Navarro · Skytalks

Esta fue la segunda parte de una investigación sobre el ecosistema de transporte público de una de las ciudades más grandes de Argentina, que mueve más de 1,5 millones de personas al día. El camino que describe Ignacio no tiene un único exploit: es hacer enumeración, leer código, encadenar vulnerabilidades, aprovechar controles de acceso débiles y diseños internos mal pensados.

Mi parte favorita de la narración fue la más extrañamente cotidiana: encontró un archivo PHP escribible que un cron sincronizaba con el servidor una vez al día. Subió una web shell, se fue a tomar una cerveza, y a las nueve de la mañana siguiente el cron hizo el trabajo por él: ejecución remota de comandos lista para usar.

Con eso consiguió acceso completo a los sistemas centrales de movilidad (buses, taxis, DVRs, tarjetas de transporte, datos de usuarios, rastreo en tiempo real y paneles administrativos). Ninguno de los hallazgos, por separado, era de los que un cliente atendía esta semana. La severidad se califica por hallazgo, pero el impacto ocurre en la cadena, y la cadena no la califica nadie.

"Your Red Team Doesn't Follow a Kill Chain" ~ Bobby Kuzma, ProCircular · Breaking Ground

▶️ Ver charla

El diagrama de la kill chain está en todas las presentaciones de la industria: reconocimiento, acceso, escalada, movimiento lateral, exfiltración, una fase después de la otra. Kuzma quiso comprobar si su propio equipo trabajaba así y, en vez de preguntarle a los operadores, se puso a grabar lo que hacían. Instrumentó las terminales del equipo, recogió 1.265 sesiones y 6.001 comandos de 95 pruebas reales, y con eso construyó un grafo en el que cada arista significa que un comando usó de verdad algo que otro comando había descubierto antes. Es justo ese contraste entre mapa y terreno lo que explica por qué cada vez más equipos apuestan por este tipo de ejercicio ofensivo controlado.

Lo que salió de ahí no se parece al diagrama. El trabajo no avanza en fases ordenadas sino en espiral, con los operadores rebotando una media de doce veces entre descubrir algo y robar credenciales antes de lograr avanzar. El 58 % de los intentos de movimiento lateral falla, y ese ruido queda concentrado en autenticaciones fallidas desde un mismo origen que casi nadie está mirando. Un tercio de las pruebas pivota gracias a un solo comando, el que él llama breakthrough command, y el mejor predictor de llegar a explotación no es cuántos comandos corriste sino qué tan bien conectas lo que ya sabes. Incluso encontró que el verdadero cuello de botella no son las direcciones IP sino los hostnames, porque son los que permiten relacionar una máquina con otra.

La herramienta con la que hizo el estudio se llama Ithildin, por las letras lunares de la Tierra Media, esa escritura que siempre está ahí pero que solo se revela bajo la luz correcta. Es justo lo que hace con los registros de una prueba de intrusión, y ya está publicada bajo licencia MIT.

"The Keyless Backdoor: Detecting GCP Workload Identity Federation Abuse" ~ Jie Wu, Shopify · Breaking Ground

▶️ Ver charla

Guardar la llave de una service account en el CI es de las cosas que todos aprendimos a no hacer, y la respuesta de la industria fue la identidad federada. Con Workload Identity Federation tu pipeline no guarda ningún secreto de Google Cloud, sino que presenta el token que le emite su propio proveedor de identidad y Google se lo cambia por credenciales temporales que actúan en nombre de una service account. No hay llave que robar, que es justamente el argumento de venta.

Lo que Wu mostró es que toda esa cadena está gobernada por apenas dos controles: la attribute condition del provider, que decide qué tokens se aceptan, y el IAM binding, que decide quién puede impersonar la cuenta. La primera forma de abusarla es la única que se ve leyendo el repositorio, porque un provider sin attribute condition junto a un binding con comodín son texto plano en Terraform. La segunda ya no se ve, porque basta una llamada de API que modifica la expresión para añadir al atacante como sujeto válido, sin que cambien ni el nombre del pool ni el del provider. Y la tercera es registrar una autoridad certificadora propia como Trust Anchor X.509, con lo cual cualquier certificado que el atacante firme se canjea por un token de Google Cloud, algo que Google no deja registrado en ningún log.

Ahí está la trampa: los Admin Activity logs vienen activados y no cuestan nada, pero solo muestran cambios de configuración y nunca el uso del token. Así que para reconstruir la cadena completa hacen falta los logs de acceso a datos de STS e IAM Credentials, que se pagan aparte y vienen apagados de fábrica. Wu tampoco vendió humo al cerrar, porque dijo de frente que la política de organización que recomienda previene el primer ataque y nada más. Es persistencia que vive en cómo se ensambla la infraestructura y no en una línea de código vulnerable, y por eso ningún escáner la está buscando.

Fuera de las charlas

Lo primero que hay que decir de Las Vegas en agosto es el calor, porque condiciona todo lo demás. El día que llegamos, a la una de la mañana, estábamos a 41 grados, y eso era fresco. Al mediodía quisimos ir a un restaurante que quedaba a siete minutos caminando y terminamos regresando para pedir un Uber. Uno entiende rápido por qué la conferencia entera vive puertas adentro, y por qué los pasillos con aire acondicionado terminan siendo el verdadero centro del evento… Al final del día, estamos en un desierto.

En esos pasillos y en las villas es donde se llenan los huecos entre charlas. El último día me metí a la villa de lockpicking a matar treinta minutos y sobre la mesa había unas esposas. Ya había abierto unas antes y conozco la técnica, así que me puse una en la muñeca, le puse el doble seguro y empecé. No cedía, porque ese modelo traía un mecanismo distinto al que conocía, o al menos al que recordaba, y encima estaba bastante gastado por el uso.

Lo intentaron cuatro personas, después el encargado de la villa, y fue él quien terminó yendo por la llave. Para entonces, los que se habían ido acercando a ayudarme ya se estaban riendo y me decían que esa iba a ser una conversación muy interesante con la TSA en el aeropuerto. Pasé de emocionado a "oh no", de ahí a resignado, y al final a "okay, eso estuvo divertido". Salí con las muñecas libres y con cuatro amigos nuevos, que es más o menos lo que la gente quiere decir cuando dice que BSides es una comunidad.

Y esa comunidad tampoco se acaba cuando cierran las salas. El martes en la noche terminé, sin planearlo, en la 8.8 Las Vegas, rodeado de la comunidad latina del Hacker Summer Camp. Uno hace este viaje por las charlas y se encuentra, además, con media Latinoamérica reunida al otro lado del continente. De todo lo que no estaba en mi agenda, esa noche fue bastante buena.

¿Lo pagaría de mi bolsillo?

Es la pregunta que siempre me hacen cuando cuento que fui, así que aquí va la respuesta sin rodeos.

Si el viaje a Las Vegas ya está hecho con DEF CON o Black Hat en la agenda, BSides entra de una. Abre la semana, la entrada cuesta una fracción de lo que cuestan las otras dos y el contenido lo justifica de sobra.

Si el viaje se hace solo por BSides, no. Si no vives en Norteamérica, yo no cruzaría un continente solo por esta conferencia. Es muy buena, pero no es a lo que uno viaja. Y hay que recordar que BSides tiene ediciones propias en muchas ciudades del mundo, que tal vez no se comparen con la de Las Vegas en tamaño, pero conservan el mismo corazón.

Y hay que tener presente que las charlas de los tracks principales quedan en YouTube a los pocos días. Lo que no se puede ver desde la casa es todo lo demás: los Skytalks, las villas, los retos y la gente. Lo que se paga no son solo las charlas, que quedan grabadas, es todo lo que pasa alrededor de ellas.

El otro lado del disco

El miércoles BSides cerraba y Black Hat abría. El mismo día, la misma ciudad, la misma gente con otro badge colgado del cuello. El lado B y el lado A del disco sonando al tiempo, y uno teniendo que escoger cuál oír.

Ese miércoles yo me pasé al lado A. Pero eso ya es otra historia.

Continuará.