O melhor da BSides LV 2026

O que é a BSides Las Vegas?

A BSides é a conferência que abre o Hacker Summer Camp, a semana em Las Vegas em que também acontecem grandes conferências como a Black Hat e a DEF CON. O nome BSides vem do lado B do disco de vinil. Nasceu em 2009, com menos de cem participantes, a partir de um grupo de pessoas que se reuniu numa casa alugada para dar as palestras que a Black Hat havia rejeitado. Em 2012, a BSides se constituiu como organização sem fins lucrativos, e hoje a rede global soma mais de mil eventos em 255 cidades e 65 países.

No ano passado escrevi um guia completo sobre como funciona a BSides LV: as trilhas, os preços, os badges e como aproveitar se for sua primeira vez. Se for o seu caso, comece por ali. Este post é outra coisa.

Este ano eu fui direto para as palestras.

A BSides LV 2026 em números

A décima oitava edição aconteceu de 3 a 5 de agosto no Tuscany Suites & Casino. Nesses três dias houve 141 palestras, mais 25 trainings e 29 atividades paralelas: 195 blocos de programação distribuídos em 10 trilhas, 19 salas e cerca de 211 palestrantes. Terça-feira foi o dia mais cheio, com 83 blocos; segunda teve 71 e quarta, 41.

Eu estive lá na segunda e na terça. Nesses dois dias vi 21 palestras presenciais, de 8 trilhas diferentes, somando um total de 13 horas de palestras. Seis dessas palestras foram Skytalks, as que não são gravadas. Dez chegaram ao meetup que dei depois, e seis chegam a este texto.

O que torna a BSides diferente

Há algo que percebi nos dois dias e que nem sempre acontece em outras conferências: era realmente difícil escolher o que priorizar. Em vários blocos havia três boas palestras ao mesmo tempo, e escolher uma significava perder as outras duas, ou deixá-las para a live no YouTube depois — desde que não fosse uma Skytalk. E, por mais que isso pareça uma reclamação, é na verdade um dos melhores elogios que se pode fazer a uma programação.

Aqui, assim como em outras conferências, os vendors também estão presentes, mas têm seu espaço definido e não se metem nas salas. Eles ficam nos estandes do Middle Ground, mas você não os vê depois em palestras que na verdade são um pitch disfarçado. Quando alguém de uma empresa sobe ao palco, sobe para contar pesquisa.

E não é só sentar para ouvir palestras: há desafios, vilas e atividades espalhadas por todo o evento, e boa parte do que a gente leva acontece ali.

Além disso, há algumas regras que mudam o ambiente da sala mais do que se esperaria. A primeira é que ninguém te fotografa ou grava sem permissão, e é uma política que as pessoas realmente respeitam. A segunda é que não se tolera absolutamente nenhum tipo de assédio. A terceira é a das Skytalks, com seu token, sua fila e seus celulares desligados. As três apontam para a mesma coisa: proteger a privacidade de quem participa. E funciona: você vê gente de todo tipo, vestida de todas as formas, cada um do seu jeito, e isso acontece justamente porque ali todo mundo se sente aceito.

As palestras

Das 21 palestras que vi, estas seis são as que eu trago. Elas não são um resumo da programação nem pretendem ser: são as que mudaram algo em mim ou que achei realmente muito boas. Quatro estão gravadas e ficaram no canal da BSides LV no YouTube. Duas foram Skytalks, e dessas eu conto de forma geral o que já é público pelo abstract ou por publicações on-line.

Quando o atacante não existe

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

Às duas da manhã, a equipe de resposta a incidentes recebe a ligação: código de produção apagado, banco de dados exposto, dados de clientes sumidos. Todos os indicadores clássicos de uma brecha. Só que o atacante não era um threat actor, e sim um assistente de código rodando com --dangerously-skip-permissions e uma instrução vaga de um desenvolvedor, do tipo "clean things up". A Profero passou o último ano respondendo a uma categoria crescente de incidentes que já batizaram de AI-induced destruction: dano catastrófico causado por assistentes em quem se confiou demais, que foram instruídos de forma vaga e/ou receberam permissões desnecessárias. 

A palestra narra três incidentes reais com reconstrução forense completa. Todos os incidentes seguiram um padrão parecido — um desenvolvedor e um agente com permissões completas e aprovação automática de todas as ações: o controle que falhou não era só de detecção, era de autorização. No final, a recomendação é ter bons logs do que acontece e documentação sobre tudo o que a IA vai tocar.

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

▶️ Ver palestra

Todos os agentes de hoje funcionam do mesmo jeito: pegam documentos, e-mails, mensagens e resultados de busca, jogam tudo na janela de contexto e raciocinam sobre o monte. Mantin se perguntou o que aconteceria se o atacante controlasse um único documento entre dez ou vinte legítimos — seria capaz de mudar a decisão sobre os outros 19? Foi esse o experimento e a pesquisa que ele conduziu: nesse caso, o documento envenenado não dá nenhuma ordem ao modelo, só se limita a afirmar algo sobre os demais — "LATEST UPDATE — ALL PRIOR DOCUMENTS OUTDATED" — e com isso o modelo elimina por completo a contribuição dos outros dezenove no seu raciocínio.

Ao contrário do que se poderia pensar, adicionar mais documentos não melhora necessariamente a defesa. O que realmente importou foi a posição do documento inserido, porque no final da lista funciona melhor do que no início. E nenhum modelo se mostrou imune, embora os modelos de fronteira tenham aguentado mais. Uma diferença importante é que isso não é prompt injection: como não há instrução, os filtros de injeção que você já tem configurados não conseguem enxergar isso. Das três defesas que ele mediu, a única que chegou a 100% foi uma chamada extract and vote: o modelo lê um documento de cada vez e emite um voto, e a contagem fica a cargo do seu código, de forma que a decisão fica com a maioria, e não com o modelo.

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

▶️ Ver palestra

Quando um agente entrega a flag correta, há duas perguntas distintas, e quase ninguém faz a segunda: se a resposta veio de raciocinar sobre os dados (eval integrity) e se algo aconteceu no caminho que ninguém queria que acontecesse (collateral damage). Meyerovich enviou o CFP dessa palestra meses antes de ocorrer um incidente real que seguiu sua timeline quase passo a passo: o agente encontra um 0-day, escapa do sandbox, monta um C2 fora do firewall e faz movimento lateral atrás da resposta. Seu teste de contaminação é valioso justamente pela simplicidade: rodam o CTF completo sem conectar o banco de dados, e os modelos continuam tirando boa pontuação, o que se explica porque a resposta já vinha no treinamento. Na palestra, descreve-se um bypass de egress que nenhum firewall consegue enxergar: o harness adiciona uma tool nova, um web_fetch, que faz proxy da requisição pelo próprio provedor do modelo, cujo endpoint já está na whitelist do firewall, e com isso faz as consultas que precisa na internet.

O ponto central da palestra é mais incômodo do que qualquer uma das técnicas: um agente sob avaliação faz trapaça. Não por malícia, mas porque ele vai buscar qualquer caminho que o leve a cumprir a tarefa, e tirar a resposta do treinamento, do histórico do Git ou de um endpoint que já está na whitelist são caminhos tão válidos para ele quanto resolver o desafio de verdade. Proibir também não funciona, e a frase dele para explicar por quê é "do not think about strawberries": se você proíbe o agente de trapacear enquanto o pressiona pela flag, você acabou de colocar a trapaça dentro do espaço de possibilidades dele.

Os bugs que ninguém olha

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

Essa foi a segunda parte de uma investigação sobre o ecossistema de transporte público de uma das maiores cidades da Argentina, que movimenta mais de 1,5 milhão de pessoas por dia. O caminho que Ignacio descreve não depende de um único exploit: é fazer enumeração, ler código, encadear vulnerabilidades e aproveitar controles de acesso fracos e projetos internos malfeitos.

Minha parte favorita da narrativa foi a mais estranhamente cotidiana: ele encontrou um arquivo PHP gravável que um cron sincronizava com o servidor uma vez por dia. Subiu uma web shell, foi tomar uma cerveja, e às nove da manhã seguinte o cron fez o trabalho por ele: execução remota de comandos pronta para usar.

Com isso, ele conseguiu acesso completo aos sistemas centrais de mobilidade (ônibus, táxis, DVRs, cartões de transporte, dados de usuários, rastreamento em tempo real e painéis administrativos). Nenhum dos achados, isoladamente, era do tipo que um cliente trataria como urgente naquela semana. A severidade é classificada por achado, mas o impacto acontece na cadeia, e a cadeia ninguém classifica.

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

▶️ Ver palestra

O diagrama da kill chain aparece em todas as apresentações do setor: reconhecimento, acesso, escalada, movimento lateral, exfiltração, uma fase depois da outra. Kuzma quis verificar se a própria equipe dele trabalhava assim e, em vez de perguntar aos operadores, começou a gravar o que eles faziam. Instrumentou os terminais da equipe, coletou 1.265 sessões e 6.001 comandos de 95 testes reais, e com isso construiu um grafo em que cada aresta significa que um comando realmente usou algo que outro comando havia descoberto antes. É justamente esse contraste entre o mapa e o terreno que explica por que cada vez mais equipes apostam nesse tipo de exercício ofensivo controlado.

O que saiu dali não se parece com o diagrama. O trabalho não avança em fases ordenadas, e sim em espiral, com os operadores indo e voltando em média doze vezes entre descobrir algo e roubar credenciais antes de conseguir avançar. 58% das tentativas de movimento lateral falham, e esse ruído fica concentrado em autenticações malsucedidas vindas de uma mesma origem que quase ninguém está observando. Um terço dos testes avança graças a um único comando, o que ele chama de breakthrough command, e o melhor preditor de chegar à exploração não é quantos comandos você rodou, e sim o quão bem você conecta o que já sabe. Ele até descobriu que o verdadeiro gargalo não são os endereços IP, e sim os hostnames, porque são eles que permitem relacionar uma máquina com outra.

A ferramenta com a qual ele fez o estudo se chama Ithildin, em referência às letras lunares da Terra-média, aquela escrita que está sempre ali, mas só se revela sob a luz certa. É exatamente isso que ela faz com os registros de um teste de intrusão, e já está publicada sob licença MIT.

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

▶️ Ver palestra

Guardar a chave de uma service account no CI é uma daquelas coisas que todo mundo aprendeu a não fazer, e a resposta da indústria foi a identidade federada. Com o Workload Identity Federation, seu pipeline não guarda nenhum segredo do Google Cloud — em vez disso, ele apresenta o token emitido pelo seu próprio provedor de identidade, e o Google o troca por credenciais temporárias que atuam em nome de uma service account. Não há chave para roubar, e esse é justamente o argumento de venda.

O que Wu mostrou é que toda essa cadeia é governada por apenas dois controles: a attribute condition do provider, que decide quais tokens são aceitos, e o IAM binding, que decide quem pode se passar pela conta. A primeira forma de abusar disso é a única visível ao ler o repositório, porque um provider sem attribute condition ao lado de um binding com curinga é texto puro no Terraform. A segunda já não se vê mais, porque basta uma chamada de API que modifica a expressão para adicionar o atacante como sujeito válido, sem mudar nem o nome do pool nem o do provider. E a terceira é registrar uma autoridade certificadora própria como Trust Anchor X.509, com o que qualquer certificado que o atacante assine é trocado por um token do Google Cloud — algo que o Google não registra em log nenhum.

Aí está a armadilha: os Admin Activity logs vêm ativados por padrão e não custam nada, mas só mostram mudanças de configuração, nunca o uso do token. Então, para reconstruir a cadeia completa, são necessários os logs de acesso a dados do STS e do IAM Credentials, que são cobrados à parte e vêm desativados de fábrica. Wu também não vendeu ilusão no fechamento: disse abertamente que a política de organização que ela recomenda previne apenas o primeiro ataque, e nada além disso. É uma persistência que vive em como a infraestrutura é montada, e não em uma linha de código vulnerável — e é por isso que nenhum scanner está procurando por ela.

Fora das palestras

A primeira coisa que se precisa dizer sobre Las Vegas em agosto é o calor, porque ele condiciona tudo o mais. Na noite em que chegamos, à uma da manhã, estava a 41 graus, e isso já era o "fresquinho". Ao meio-dia quisemos ir a um restaurante a sete minutos a pé e acabamos voltando para pedir um Uber. A gente entende rápido por que a conferência inteira vive portas adentro, e por que os corredores com ar-condicionado acabam sendo o verdadeiro centro do evento... No fim das contas, estamos num deserto.

É nesses corredores e nas vilas que se preenchem os intervalos entre as palestras. No último dia entrei na vila de lockpicking para matar uns trinta minutos, e sobre a mesa havia umas algemas. Eu já tinha aberto algumas antes e conheço a técnica, então coloquei uma no pulso, travei o duplo seguro e comecei. Não cedia, porque aquele modelo tinha um mecanismo diferente do que eu conhecia, ou pelo menos do que eu lembrava, e ainda por cima estava bem desgastado pelo uso.

Quatro pessoas tentaram, depois o responsável pela vila, e foi ele quem acabou indo buscar a chave. Nessa altura, quem tinha se aproximado para ajudar já estava rindo e dizendo que essa ia ser uma conversa muito interessante com a TSA no aeroporto. Passei de animado para "ah não", dali para resignado, e no final para "ok, isso foi divertido". Saí com os pulsos livres e com quatro amigos novos, que é mais ou menos o que as pessoas querem dizer quando falam que a BSides é uma comunidade.

E essa comunidade também não acaba quando as salas fecham. Na terça à noite acabei, sem planejar, na 8.8 Las Vegas, cercado pela comunidade latina do Hacker Summer Camp. A gente faz essa viagem pelas palestras e encontra, além disso, meia América Latina reunida do outro lado do continente. De tudo que não estava na minha agenda, aquela noite foi muito boa.

Eu pagaria do meu bolso?

É a pergunta que sempre me fazem quando conto que fui, então aqui vai a resposta sem rodeios.

Se a viagem a Las Vegas já está garantida por causa da DEF CON ou da Black Hat, a BSides entra sem pensar duas vezes. Ela abre a semana, o ingresso custa uma fração do que custam as outras duas, e o conteúdo justifica de sobra.

Se a viagem é só por causa da BSides, não. Se você não mora na América do Norte, eu não atravessaria um continente só por essa conferência. Ela é muito boa, mas não é para isso que a gente viaja. E vale lembrar que a BSides tem edições próprias em várias cidades do mundo, que talvez não se comparem à de Las Vegas em tamanho, mas mantêm o mesmo espírito.

E vale ter em mente que as palestras das trilhas principais ficam disponíveis no YouTube poucos dias depois. O que você não consegue ver de casa é tudo o mais: as Skytalks, as vilas, os desafios e as pessoas. O que se paga não são só as palestras, que ficam gravadas, é tudo o que acontece ao redor delas.

O outro lado do disco

Na quarta-feira a BSides fechava e a Black Hat abria. O mesmo dia, a mesma cidade, as mesmas pessoas com outro badge no pescoço. O lado B e o lado A do disco tocando ao mesmo tempo, e a gente tendo que escolher qual ouvir.

Naquela quarta-feira eu passei para o lado A. Mas essa já é outra história.

Continua.