The Mayfair neighborhood in Northwest Chicago is known for its dense stock of historic Chicago bungalows, which is so extensive that the North Mayfair Bungalow District was added to the National Register of Historic Places in 2006. Mayfair’s bungalow history is not just architectural. The neighborhood drew working- and middle-class families from different ethnic backgrounds around a shared goal: owning a solid, modern home. That made it the perfect place to hold BSides312 2026, where people with different paths, skills, and roles gathered around the shared work of defending old systems, building durable foundations, and keeping inherited infrastructure useful under new pressures.

"Chicago's Biggest Little Non-Profit Cybersecurity Conference" returned to Chicago on May 16, 2026, with two talk tracks, community villages, lockpicking, CTF, and an in-house after-party. This event is run by and for the local community. More than 400 people showed up, with the 400th ticket sold the day before, and the organizers opened with the kind of inside jokes and practical logistics that make a local security conference feel lived in. The Keynote from Heidi Potter, COO at Turngate, "Community Doesn’t Start With a Conference," reinforced the mood that we were there for each other, and the event was just one more way for us to collaborate, not the sum of how our community operates. 

Here are just a few choice highlights from the third annual BSides312. 

Open Source Poison and the Basics We Keep Skipping

The session by Sean Juroviesky, Senior Security Engineer at SoundCloud, called "OpenSource Poison: A Long Ignored Risk," began with a familiar contradiction that open source runs everything, yet much of it remains underfunded. It is loosely maintained, but also deeply trusted by default across the enterprise. We keep building on shared components, shared maintainers, and shared trust, while pretending the foundation has infinite capacity.

The session centered on open source poisoning, where attackers compromise the trust around a package rather than breaking in through the front door. Attackers build a positive reputation, submit something subtle, then use it to steal developer npm tokens and pull malicious packages into the ecosystem. The same pattern showed up across stolen repositories, exposed tokens, compromised tooling, and malicious versions tagged as latest. Sean's attack examples are largely also covered by our team as well.

Sean gave us some practical advice: Stop leaning on personal access tokens where better options exist. Do not automatically trust :latest, and pin dependencies with cryptographic hashes or digests. Tags are not immutable, and attackers know how to move them. Lock down GitHub Actions, restrict runner permissions, remove passwordless sudo, and treat secrets in continuous integration and continuous delivery systems as high-value targets.

In the era of AI-assisted development and vibe coding, the split is becoming clearer: some developers are moving faster than their guardrails, while others are stuck firefighting the damage. The answer is not one heroic cleanup. It is a secure software development lifecycle, continuous monitoring of non-human identities and access, and an application security process that keeps returning to the basics. 

Security is not a point in time. Bad habits build up, so better habits have to be built on purpose.

Forensics Starts Where the Logs Get Quiet

In the session from Dr. Cathy Ullman, Principal Technology Architect, Security at the University at Buffalo, called "So, You Want to be a Forensicator...," she presented digital forensics as a discipline of patience, evidence, and pressure-tested curiosity. Her story started with a new “forensicator,” a networking team under pressure, and a suspicious Russian IP address. Event logs were just the tip of the iceberg in this case, as attackers know how to avoid or manipulate them. Cathy led us on the deeper, real path a forensic investigator would take and the knowledge and skills they would need. 

In digital forensics, the work is collecting, preserving, and analyzing evidence from digital media in a forensically sound way. Chain of custody matters. So does proving that the original evidence was not changed. A write blocker, for example, helps acquire a disk image without altering the source. That separates forensics from incident response: one is the detective work of preserving and interpreting evidence, while the other is the firefighting work of identifying, managing, and mitigating an active breach.

Cathy explained that doing this work requires curiosity, persistence, patience, objectivity, communication, attention to detail, and the ability to work under pressure. The work can mean long hours, late nights, and uncomfortable material. It is not what television sells. But for the right person, it can be rewarding, puzzle-like work with no typical day, a helpful community, and a future-proof purpose. Her advice was that in an era of AI-assisted security tooling, you need to understand networks, operating systems, file systems, cloud control planes, and the evidence in front of you. The data is the data. Your job is to interpret it honestly.

DNS Is the Old Infrastructure Everyone Still Trusts

In the session from Matt Scheurer, host of the ThreatReel Podcast, "Definitely Not Secure (DNS)," he presented DNS as a foundational system whose familiarity makes it easy to underestimate. The internet still leans on old basics. DNS converts names into addresses and must always be publicly addressable. That makes it useful. But there is no built-in, foolproof way to entirely secure it, which also makes it risky.

The session moved from records to attacks. Matt quickly walked us through explanations of how A records and CNAME records work. He talked about how TXT, MX, NS, and SOA records each carry trust. TTL, or time to live, controls cache timing. He demoed the tools nslookup and dig to help reveal what is exposed.

DNS was built for reachability first. Trust came later. Many requests still expose where a system is trying to go. Caches can also be poisoned when a resolver accepts a bad answer. Once cached, that answer can send users to the wrong place until it expires. Attackers can hide commands inside DNS queries. They can also encode stolen data into those lookups. Configuration matters, especially when the protocol is old and well understood by attackers. 

In the era of AI, teams still need to know the plumbing. Refresh the basics. Watch the traffic. Never trust, always verify.

Active Directory Remembers What Teams Forget

Nikos Vourdas, Senior Offensive Security Consultant, presented "The Walking Dead of AD: Uncovering rare DACL-led escalation and a BloodHound-integrated tool." He explained Active Directory escalation as a story of hidden permissions and old assumptions. The account he could access was disabled. The user looked dead. BloodHound showed no clean path to admin. On paper, there was nothing obvious to chase.

The danger was in the permissions that no one had cleaned up. Active Directory is not just users and groups. It is a web of objects, rights, and old decisions. A disabled account can still matter if it holds the wrong access. A forgotten permission can become a path. A past admin state can leave behind risk long after the role is gone.

That is why this class of issue is so dangerous. It does not require a flashy exploit. It requires a misconfiguration, a stale object, and an attacker who understands what the tools are doing. Once an object becomes privileged, treat it as privileged forever. Review permissions on disabled accounts. Watch for accounts being re-enabled. Check both inbound and outbound rights. 

Tools can show the path, but defenders still need to understand the why. 

Old Foundations, New Pressure

Across BSides312, the conversations were about the cost of forgetting the basics. Open-source packages, DNS, Active Directory, logs, cloud controls, and CI/CD pipelines are not background plumbing. They are the places where modern work happens. They are also where old assumptions quietly become new attack paths. 

AI may be changing how fast teams build, but it has not changed what systems depend on. Trust, identity, access, and evidence still decide the outcome.

Speed Makes Small Mistakes Bigger

The era of AI-assisted development makes this sharper. Faster code does not automatically mean safer code. It can mean more dependencies, more secrets, more automation, and more “temporary” decisions that never get revisited. 

The danger is not always a zero-day. Sometimes it is a stale token, a mutable tag, a poisoned cache, or a disabled account that still has dangerous rights.

Evidence Still Matters

Logs help, but they are not the whole story. Attackers know how to avoid them. Defenders need to understand the system well enough to know where else to look. Teams are drowning in alerts, dashboards, and AI summaries. Those tools can help, but they cannot replace judgment. The data is still the data. Someone has to preserve it, question it, and interpret it honestly.

Community Is Infrastructure

Security is not just tools and tactics. It is people, space, culture, and intention. Conferences do not create communities. They reveal them. Every technical talk pointed back to human systems. Maintainers need support. Developers need guardrails. New analysts need mentors. 

Communities are not soft extras. They are how people survive hard seasons and learn faster than the threat landscape changes.

Build From What Is There

Security does not improve because someone buys a tool or attends a talk. It improves when teams look honestly at what already exists, then make it better on purpose. Review the old permissions. Fix the old records. Clean up the old tokens. Teach the old protocols. 

Support the people carrying the work. AI raises the tempo, but it does not erase the foundation. The basics still matter because everything new is being built on top of them.

The Work Starts Where We Are

Security work can feel endless, because it is. The systems change. The tools change. The pressure changes. In that spirit, your author gave a talk on how we got to where we are in DevOps and what the potential future of workload identity and access looks like.

The work still comes back to people who are willing to ask better questions, share what they know, and help someone else get one step further than they were yesterday. The basics matter, but nobody can do it alone.

We encourage you to get involved in your local security community. Show up to conferences, meetups, do a CTF, and join the hallway conversation. If you are already a member of a community, be the someone who takes care of those newcomers who look unsure. Volunteer when you can. Ask questions. Teach what you just learned. 

Security improves when the people doing the work are connected, supported, and willing to build on what is already there.