Chicago's famed “L” trains run on the oldest rapid‑transit infrastructure in the U.S., dating back to the 1890s. The heart of the whole system is "The Loop," where almost all the lines intersect, helping riders get anywhere they need to for over 130 years. The juxtaposition of legacy systems still carrying modern loads feels apt for the digital age. Old ideas of perimeter, access, and identity still carry massive weight, even as the environment has transformed. It made downtown the perfect backdrop for BSides Chicago 2025. 

Around 700 attendees gathered at the massive Hilton Chicago for 2 days of training, workshops, talks, a CTF, and a lot of conversations and fun. Thirty three speakers were able to share their knowledge and experience throughout the event. A theme that ran throughout most sessions was that identities matter more than ever, yet the rules of the game have shifted dramatically. Human and non‑human identities are the real control plane in security, especially in cloud and hybrid infrastructure. 

Here are just a few highlights from this year's BSides Chicago. 

Control‑Plane Abuse and Identity Tactics

In the session "Living off the (land)cloud: Scattered Spider and the cloud control plane" by Scott Hawk, VP and Fractional CISO at Velaspan, the focus was on how adversaries such as actor group Scattered Spider are bypassing conventional detection by abusing cloud‑control‑plane identities and orchestration layers. Scott walked through breach stories, including the 2019 Capital One breach, where IAM was the entry vector, and the 2023 MGM/Caesars breach that made heavy use of vishing (voice phishing). He explained that data‑plane attacks are noisy and attackers increasingly target the control plane, where permissions, roles, APIs, and identity assumptions live.

He dissected how an attacker will move as a low‑priv user to locate a role and assume that set of permissions, using MFA‑bypass techniques like SIM swap, MFA bombing, and voice phishing. After that, they use device persistence at the tenant level, cross‑tenant Federation abuse, and even Azure serial console exploitation. In one demonstration, even a “low‑privileged” user in CloudShell could enumerate policies, attach roles, and initiate role chains.  The defense for all of this is deception technologies like honeytokens, which trigger an alert where normal activity might not.

From a defender’s vantage, this flags two imperatives. First, we must cast deception, including "honey accounts," into cloud IAM. And we must expect that the control plane is the battlefield. Detection via legacy EDR/XDR may not surface this because workloads appear legitimate until they assume privilege. The key operational risk is identities with overly broad roles that turn the cloud control plane into a stealth attack surface.

Service Principal Over‑Privilege

In the presentation by Nikos Vourdas, Senior Cyber Security Consultant at EY, "May the Least Privilege Be With You: Exposing the Dark Side of Azure Service Principal Permissions," the lens the spotlight shifted to non‑human identities, specifically service principals (SP) and enterprise apps, in Microsoft Azure and Entra ID environments. He showed how misconfigurations lead to full takeovers. Typical defenses focus on user identities while entirely ignoring the “ghost army” of service principals, delegated API permissions, enterprise applications with owner privileges, and legacy app connectors. 

Through research, he found that in nine out of ten cases, a low‑privileged user who owns any SP could change its secret, pivot to global‑admin, and take over other enterprise apps. He has seen cases where attackers use this to abuse Graph API permissions to read/write mailboxes and even deploy Intune line-of-business (LOB) apps for Intune to execute code on devices; all without requiring a traditional admin console login.

Nikos explained that the cloud risk here is layered. First, service principals exist across both on‑prem and cloud. Second, conditional‑access exclusions, commonly used for defining “corporate network” tokens, create supervisory blind spots. Third, device‑management APIs act as an under‑tracked lateral pivot vector. 

He urged defenders to treat every app owner as “high‑privileged users”, review SP secrets as rigorously as admin credentials, and monitor application owner activity with the same vigilance applied to human identities. For a practitioner, this expands the identity threat surface significantly: it's no longer just IAM for humans, but IAM for code, services, and federated objects.

Kubernetes Hygiene Isn’t Optional

In the joint session by Jie Wu, Senior Security Engineer, and Pulkit Garg, Infrastructure Security Engineer, both at Shopify, "Pods, Privileges, and Other Things That Keep Security Engineers Up at Night," the focus was on containers, specifically Kubernetes. The duo opened with a realistic scenario that you deploy a cluster first and assume “we’ll lock it later.”  Unfortunately, by default, Kubernetes is not secure out of the box. They listed the ten worst misconfigurations, including running containers as root, no resource limits, no network policies, and running privileged containers. 

However, Kubernetes actually has many built‑in security options. PodSecurityStandards, RBAC, namespaces, and resource quotas are all configurable, yet are not activated when you first set up your clusters. As a result, these really powerful controls are rarely enabled or enforced. The speakers also introduced a stack of open source defence tooling: They walked us through using Falco for runtime detection, Trivy for image scanning and IaC misconfig detection, and Kyverno/OPA for policy enforcement.

They argued that cloud native workloads can be the pivot staging ground for identity abuse and control‑plane compromise. If a container runs as root, a compromised workload can jump to the underlying node, then to the cloud provider’s resource management layer. In Kubernetes‑native operations, you cannot assume isolation. It is up to you to enforce least privilege, resource hygiene, and runtime observability. The operational risk is that DevSecOps teams treat Kubernetes like a traditional VM fleet rather than a dynamic orchestration system, resulting in misconfigured clusters becoming stealth attack infrastructure.

Identity Has Been The Perimeter All Along

The silent thread weaving through all sessions was that identity is not just an IT concern; it is the basic unit we need to defend in our organizations. As cloud adoption, agentic automation, machine identities, SaaS integrations, and Kubernetes orchestrations all multiply, the classical notion of zone‑based perimeter vanishes. We have to stop thinking in terms of network edge, DMZ, and VPN as the primary ways to stop attacks. Rethinking how we treat identities, permissions, service principals, and control‑plane APIs is how we can actually affect change in a world where attackers are only ever moving faster. The modern attack surface is the identity and orchestration layer, which is constantly shifting, under‑monitored, and deeply complex. 

We are watching attackers increasingly exploit identity chains to go from a low-priv user all the way through privilege escalation, resulting in data exfiltration faster than ever. These paths are stealthy and often look legitimate from a workload perspective. Because they look like “employees doing work,” traditional EDR/XDR systems may not surface alerts. Without a rigorous least‑privilege approach and context‑aware observability, the blast radius of a compromise only widens.

Shifting Our Security Postures

Defenders must embrace context‑aware IAM. In practice, this means we need to treat non‑human identities, including service principals, enterprise apps, and machine accounts, just like human identities. We should focus on tracking secrets, monitoring access, and narrowing permissions wherever we can.

Deception tools, like honeytokens and honey accounts, need to be deployed globally, not only on hosts but also in IAM , alerting everyone when an attacker has assumed that identity. This one move toward embracing deceptive security can help organizations shift from a static “checklist compliance” stance, where people call it good enough when we enable MFA, to a risk‑based and context‑aware posture.

Orgs should strive to prioritize signal over noise in detection. Defenders are frankly overwhelmed, as so many security professionals face burnout and are underfunded. We can move to a world where alerts only happen when the chain of identity assumption or cross‑tenant trust is triggered, not every low‑severity anomaly.

Automate rotation and hygiene of low‑use but high‑impact identities. Don’t wait for an audit cycle. For many organizations, the biggest risk is standing permissions that haven’t moved in months or years.

Friction points for security teams

Complete visibility into service principals across hybrid and cloud environments is hard. Many orgs treat “apps” as stakes outside the scope of IAM. Enabling PodSecurityStandards and runtime detection in Kubernetes requires DevOps cooperation. Deception at scale, implementing thousands of honey‑accounts/tokens, is no longer a nice-to-have; it is how we are going to tell when an attacker has already breached our perimeter. Designing alerts based on identity chain behaviour instead of volume requires new tooling, new skills. 

Senior leaders must budget for identity observability, detection engineering, and support cross‑team coordination between IAM, cloud, DevSecOps, and IR. We need a shift in mindset from “we defend networks and endpoints” to “we defend identities, privileges, and trust relationships.” 

Machine identities, agentic automation, and SaaS federations are not edge cases. As defenders, we must accept that permissions are dynamic and the control plane is contested. Our architectures must shift from fortress walls to fluid identity zones where trust is managed, not assumed.

Close the Loop on Identity Risk

The biggest benefit to BSides Chicago was the opportunity to commiserate with other security professionals who are waging the same battles, one after another. Your author was able to give a session on where we could go with federated identities for NHIs across systems, which is actually possible right now on most cloud providers.

Getting there, like anywhere else in security, is going to take us all communicating and sharing this vision of a future where we treat identity as the real perimeter. We need to give humans and machines the same guardrails with least privilege, rotation, and context-aware monitoring. Plant honeytokens in IAM and trigger on identity chains, not volume. If we do this, your cloud deployments stay fast without handing attackers the keys.