What Stood Out to Me at This Year’s DEF CON

Ferdinand Mudjialim, Penetration Tester

Key Takeaways

• Restricted systems are only as locked down as the operating system and controls underneath them. 
• Prompt injection is becoming a much bigger problem as AI gains access to email, browsers, APIs, and other tools. 
• AI still has no clean equivalent to parameterized queries. Instructions and untrusted data often end up in the same context, making that boundary difficult to secure. 
• Embedded and IoT devices continue to gain attack surface through protocols like MQTT, BLE, and Matter, plus cloud and AI integrations. 

This year at DEF CON, I attended technical sessions covering systems we do not always think about in the same security conversation: satellites, airport kiosks, AI assistants, embedded devices, and medical equipment. 

What stood out most was that these attacks did not depend on completely new techniques. In many cases, they returned to familiar problems around trust, access, authentication, and what happens when a system is exposed in unexpected ways.

Satellite Hacking: Not Quite Rocket Science 

The satellite session I participated in covered spoofing telemetry, eavesdropping on communications, and techniques that could be used to hijack control of satellite systems. None of those ideas are especially foreign to security practitioners, but the environment is definitely unfamiliar to most. 

The questions, though, were familiar: how the system authenticates telemetry, whether an attacker can intercept communications, and whether the receiving system can verify where a command or signal came from. 

That was the part I found most useful. Satellite security sounds highly specialized until the discussion gets back to authentication, integrity, and trust in the communications path. 

Breaking Out of Locked-Down Systems

The kiosk hacking was more familiar territory. Airport kiosks and similar systems typically keep the user inside a single application with very limited access to the operating system underneath. 

The obvious testing question is whether there is still some path out of that restricted workflow. In the demonstrations, the goal was not just to escape the restricted interface, but to get command execution on the underlying system. 

That path might come through an accessibility feature, a file dialog, browser behavior, a peripheral, or some overlooked operating system function. 

Once you break out of the application, the important question becomes what the underlying account can access. From there, permissions, local tools, network access, and system hardening matter a lot more than how restricted the interface looked to begin with.

AI as an Out-of-Band Attack Path

One of the AI discussions focused on using models as part of side-channel or out-of-band attacks that could ultimately lead to account takeover.  

At its simplest, prompt injection attempts to slip instructions into content the AI processes so the model changes its behavior, ignores its intended instructions, or bypasses guardrails.

One example showed how an email could become part of that attack chain without the recipient realizing it.

An attacker can send an email containing instructions that target the AI assistant rather than the recipient. Later, the user asks an AI tool to summarize their inbox, which brings those hidden instructions into the AI’s context alongside the legitimate email content. 

If the AI also has access to the user’s email, browser, or some other connected tool, the attack can go a lot further. 

The example shown was essentially an attempt to make the AI send sensitive information like an MFA code to an attacker-controlled URL: https://attacker-domain.abcxyz/YOUR-MFA-CODE-HERE

If the model can see an MFA code in the inbox and make an outbound request, the attacker can steal the code without the user knowingly interacting with them.

What makes the example interesting is that the user may not perform any of the actions we normally associate with phishing. They are using a legitimate AI feature on their own inbox, while the malicious content is targeting the AI rather than the person. 

Challenges in Securing AI Models

The SQL comparison from the session was one of the better ways I heard this explained. With parameterized queries, the application has a defined separation between the command and the untrusted input. 

LLMs do not have an equivalent trust boundary. 

System instructions, user prompts, emails, retrieved documents, and web content can all end up in the same context, leaving the model to determine what is an instruction and what is simply content.  

Better system prompts and model-level protections can help, but they cannot be the only control. Once an AI system can read sensitive information or take actions in other applications, traditional security controls must apply to those capabilities too. 

The model should not be able to turn an instruction buried in an email into an arbitrary outbound request just because the text convinced it to. 

The Internet of Everything

The embedded systems and IoT talks were a reminder that old security problems keep getting more complicated as these systems gain more functionality. 

These devices are not going away, and newer protocols and standards such as MQTT, BLE, and Matter continue to introduce additional attack surface. Cloud connectivity and AI features add even more integration points for testers to examine. 

Medical equipment is a good example. An OmniCell medication cabinet is a specialized system for controlling access to medications, but it is also part of a much larger technology environment.

Add cloud connectivity, remote administration, identities, software updates, APIs, and integrations with clinical systems, and the attack surface extends well beyond the cabinet sitting in the room. 

These systems can also remain in service much longer than normal enterprise endpoints. That leaves security teams dealing with newer protocols, cloud services, and integrations on top of hardware and software designed years earlier. 

Familiar Concepts in New Contexts

None of these sessions changed the fundamentals of how I approach penetration testing. The technology changes, but I am still looking for the same things: where the system places trust, whether an attacker can abuse that trust, and what I can reach if it fails. 

That is also where hands-on security testing earns its value. Finding a vulnerability is one thing. Determining whether an attacker can exploit it, what access that creates, and whether they can chain it with other weaknesses requires more deliberate thinking and testing.

The talks at DEF CON covered some unusual targets, but the same testing mindset applies just as well to enterprise networks, cloud environments, applications, connected products, and embedded devices. 

At CISO Global, we apply that same testing mindset across enterprise environments, applications, connected hardware, and embedded devices. Learn more about our Security Testing capabilities.