Speakers

Max Turner is a cybersecurity leader at Red Sentry, where he focuses on turning complex security challenges into clear and actionable insights.  He works closely with the Pentesting, Marketing, Sales, Engineers, and Leadership to foster knowledge sharing and career growth across the house. With a diverse background spanning everything from logging to teaching to window cleaning to logistics coordination, he began his IT career in network administration before discovering a love for cybersecurity and moving into penetration testing.  He has a knack for leadership and has grown into a leadership role through a consistent, solutions-first mindset and a natural tendency to gather and nurture positive communities wherever he goes.

Known for his ability to translate technical depth into real-world impact, Max works with both technical and non-technical audiences, whether advising clients, collaborating across teams, or speaking at industry events.  He has the right mix of technical knowledge, curiosity, and approachability to close the gap between the deeply technical and business side of the house.  Having worked for several years as a teacher, he centers his approach on making cybersecurity practical, understandable, and relevant beyond just the technical details.

Originally from the United States and based in Japan since 2015. Max loves exploring new places and has a habit of finding like-minded friends wherever he goes. Outside of cybersecurity, he is a husband, father of three, runner, casual gamer, and avid rock climber who believes that storytelling and the occasional dad joke can make even the most complex topics interesting and approachable for anyone.

Linkedin – Max

Why do hackers’ ears prick when they find out you code using AI?

Recently, our team heard about a case where an AI coding agent wiped a company’s entire production database, along with its backups, in seconds.  This is not an AI going rogue story; it’s an access control failure at machine speed.  We are starting to see versions of that same pattern show up regularly in real applications.  In this talk, I am going to explain why these patterns excite our team as ethical hackers, and why less ethical hackers will be just as excited about them.

Situations like the code-wiping agent signal a shallow implementation and build, likely shipped under a tight deadline, which is nothing new.  The difference in this case is that the application’s architects did not have to build its code block by block. They didn’t have to research, test, fail, and repeat until they had a solid working product.  The product they have works, but it is likely that few, if any, of the engineers have a solid working knowledge of it at the source code level.  They were able to ship the code faster than it took them to understand it.

In this talk I am going to give some examples of findings that our team has uncovered while testing applications built utilizing AI.  These apps are all either AI-code-assisted, integrated with AI functionality, or completely vibe coded.

Broken Access Control is something we have been writing on our reports for a long time and we see it often in apps built using AI.  It can be accomplished in a number of ways.  Recently, we did some work on an app that utilized the Supabase Backend-as-a-Service platform.  Instead of using a low-privilege ‘anon’ key in its browser, the vibe-coded app initialized Supabase with the ‘service’ role key, buried in the front-end JavaScript. This key basically allows us to do whatever we want in the back-end of this app, access and act as whatever user or tenant we want, and see data that had never been exposed in the front-end UI.  Big problem.

Another common thing we see is exposed API keys.  Recently we tested an AI-built app that revealed its Gemini api key. Using that key, we got access to our client’s internal AI model.  Not only could we use the model to browse and view internal files, but abuse of that vulnerability would put a severe financial strain on the client, as they would be responsible for the bill for all tokens used.

There are some applications we test that are integrated directly with an LLM or MCP.  The team can get wild with those.  Very recently we tested such an environment, and it had a limited Sonnet 4.6 model.  Our tester prompt-injected the model to run an assessment inside its own Firecracker microVM using its code_exec tool.  It found a Claude user with CLI, but no exposed tools.  The team then used the application’s own MCP as a wrapper over the Claude CLI to run it with full system access.

The above are good examples of Overexposed APIs and Overprivileged systems, including the 9-second database wipe we opened with.  In addition to these we will explore some IDOR/broken object-level authentication and missing guardrails like rate limiting/logging.The recurring theme is that most of the time we aren’t exploiting the AI, we are exploiting the access and assumptions behind it.