Join Chief Attack Engineer Zach Hanley and Exploit Developer James Horseman for an eye-opening keynote session where they’ll discuss in detail how the hacker mindset can be applied to seemingly daunting tasks in order to make them more approachable.

Zach and James will show how they approached their first Pwn2Own contest and how they discovered a command injection RCE vulnerability affecting nearly every Lexmark printer. They’ll also share why they think it went unnoticed in previous research and why current open-source static analysis tools can miss this simple bug.

Finally, they’ll release the exploit POC and an additional POC to dump credentials during engagements.

Yeah, it‘s the usual Finux talk. I‘m going to talk about something bizarre and unrelated to security and then find similarities and walks away from said bizarre and unrelated thing which can be applied. If i manage to pull it off is another question entirely. If you‘ve been to GrrCON anytime over the past decade you‘ll have probably seen me try this before. I‘ve been speaking at GrrCON for years, I‘m the guy with the memes who comes from Scotland, talks a lot about history. So this year, I’m going to try boats.

Boats! Yes, you read right I’m going to be talking about boats. Boats are pretty epic, they‘re also very scary, and crazy dangerous. They have a long history, in fact they‘ve helped shaped a lot of it. From exploration to being used as weapons, their role in trade, to the mass migration of people, they‘ve played a crucial part. What i have learned in a year, is that a sailors idea of safety and security is terminal than a nerd from Scotland knew. This talk is not about hacking a boat, barrel roles in a sailboat is a proper terrible idea!

I will go off topic, i will swear, probably a lot, and you‘ll not learn anything you couldn‘t have googled yourself. I‘ll be honest with you all now it‘s tempting to load this entire talk with jokes about seamen. Don‘t judge me, you‘re at GrrCON too! You’ll not find any real walks aways but you might learn a few interesting things, some of them might even be about security.

You should probably go see the other talks 😉

In this talk we cover 3 important topics related to Red Teaming.
We talk about how our approach must change when doing engagements. We need to focus more on how do really help our client. Breaking the client’s network or helping them improve their security which is more imperative really?

We focus on what brings better value for the client. Showing them how leet you can be with your mad Red Teaming skills or by showing them how trivial a breach can be and educating the client’s employees on how to be better secure.

Knowing nice big technical words is great and all. Yet wouldn’t be even better if we talked in ways that everyone can fully understand and therefore create lasting change and improvement to the client’s security posture.

Imagine pouring your heart and soul into a software build, crafting a new piece of our digital world with all the features, functionality, and user experience that has made modern life so darn convenient. Your work is the envy of your peers, and the code shipped without a hitch. Excellent.

… and then, the gloomy presence of a security specialist tears it all down. They’ve found an exploitable security bug, you won’t be shipping your code, and their suggestions on remediation are at odds with everything in your tech stack.

For many developers, this is the harsh reality of their experience not just with the AppSec team, but with cybersecurity in general. “Security” has negative connotations for them, and it really isn’t a priority when feature-building at speed must take center stage. Developers are key to stemming the flow of common vulnerabilities, and this tension must dissipate if a true DevSecOps environment is to flourish. This session will detail data collected from the results of 100,000 developers playing code-based security challenges, showcasing the current landscape of developers and their security skills, as well as where there is room for significant improvement.

Elevating developers to become not just security-aware, but security-skilled, has been a hot topic for many years, but if the amount of breaches is any indication, the current approach is failing. To understand the right approach to ignite their security fire is to understand the developer, and bring the knowledge to their playground, not the other way around. Pieter Danhieux will leave attendees with a viable direction on where their security program can make

Explore, and prepare for, real-world scenarios that enable attackers to exploit common cloud security mistakes. From insecure S3 buckets to weak IAM permissions, you’ll discover how missteps in network configurations can create a complex cloud environment and hinder your ability to protect against attackers.

In this session we suggest ways to turn your AWS infrastructure into a more secure environment that frustrates adversaries and, ultimately, guards against access to your sensitive data. You’ll learn actionable ways to deploy deceptive resources, such as honey tokens strategically placed within your AWS environment to bait potential attackers. With these seemingly legitimate credentials, tokens, or files intentionally scattered throughout your infrastructure, honey tokens lure unauthorized access attempts and trigger alerts – raising red flags the moment they are accessed or abused. By leveraging honey tokens, you create a virtual minefield for intruders, drastically increasing the likelihood of early detection and enabling a swift response to unauthorized access attempts.

Gartner predicts that over 40% of organizations will adopt Application Security Posture Management (ASPM) by 2026. It’s taking off with the tires smoking, but what’s the excitement about?
ASPM solves big issues that have been vexing enterprises for years – poor security visibility into complex developer environments, lack of context to quickly address security issues, and siloed security responsibilities that stifle productivity and speed. All of this results in a strain on developers, AppSec teams, and traditional security tools that’s reached their limit, and ASPM is finally here to help. Join me as I define ASPM, share details on how it helps, and explore the key benefits to get you on board:

Automate security controls from code to cloud so you can do more with less
Improve prioritization on most critical business risks to improve efficiency and effectiveness
Break down inefficient security silos and boost team productivity

Many closed doors can be kicked open by attackers willing to undergo offensive Java code review and crucial initial access can be established by offensive teams willing to go the extra mile. However, going through that research process for the first time can be intimidating. Acquiring the knowledge necessary for Java offensive code review comes through trial and error, which can delay progress by weeks or months.

We’ve recently identified multiple pre-authenticated remote code execution zero days in enterprise Java software. During this presentation, you will learn the effective workflows, strategies, and techniques leveraged for these zero days. You will also hear more about the identified vulnerabilities, the methodology that led to them, and the development process of effective production-ready exploits. We’ll also outline how to avoid common pitfalls when navigating the responsible disclosure process to ensure a successful resolution.

Let’s face it, as an industry, we are not doing a great job with vulnerability management. Despite the growing awareness of its importance, most organizations are still struggling to get a handle on their software attack surface, let alone patch.
Meanwhile, the number of vulnerabilities discovered each year is constantly growing, and we have more and more code running in our production environment that we didn’t write. Events like Log4Shell have led to increased visibility into the software stack and the growing adoption of SBOM. However, this increased visibility comes with more noise, making it challenging to prioritize vulnerabilities effectively. Patching known vulnerabilities known to be exploited in the wild with an existing patch, which should be the easiest task in cybersecurity, seems to be beyond the grasp of many organizations.
While these gaps only widen over time, we seem to be doing the same thing and expecting different results. Something has to change.
In this talk, we will explore the challenges of vulnerability management and highlight potential solutions. We will discuss why a paradigm shift from “patch everything” to “patch what matters” is necessary for us as an industry to keep up with the evolving threat landscape. We will discuss why prioritization and automation are key elements of this paradigm and how frameworks and standards like CSAF and VEX that can help us get there.
Since some building blocks required to allow for this vision are still being built or have not yet gained wide adoption, practitioners need to know them, understand their limitations, and weigh in to drive improvement and adoption.
I hope that by the end of this talk, attendees will gain a deeper understanding of the challenges and opportunities of vulnerability management and leave with practical insights on how to improve their organization’s security posture.

We get it. MSP’s suck. They often aren’t security focused, they let their clients get pwned, and they are generally a nuisance. Their own homes are often not in order before helping their SMB clients implement their own technology.

But let’s consider the world without them – millions of small businesses using the receptionist or office manager to manage IT. What could go wrong?

They are in an unregulated world, a collection of technology enthusiasts and visionaries turned service providers. No standards. No Regulations. Uneducated SMB Consumer. Extreme EBITA Multipliers and consolidation without real re-work of “What risk level is acceptable”, and “Should we follow processes and procedures?”

Matt and Jason discuss some of the struggles MSP’s face, some of the initiatives going on to make them better, and how the security community can help us all be better.

Security researchers around the world are doing a great job reporting security vulnerabilities to affected vendors and companies to help protecting users world-wide. We all enjoy learning the technical details and stories behind the vulnerabilities. However, the process of Coordinated Vulnerability Disclosure (CVD) is not always straightforward as it seemed. When a coordinated vulnerability disclosure involves multiple vulnerability and/or vendors, there are a lot more goes into the disclosure process. The Microsoft Vulnerability Research (MSVR) program has been a part of many different CVDs and we are the middle-man that ensures the disclosure is done responsibly.

This talk will present you with some insight into the “invisible” but important portion of the CVD process that we don’t often see or hear about that involves the case management team (“the cat wranglers”) that coordinates these disclosures.

Ask an organization what its most sensitive asset is, and they will likely say a server that aligns to the CIA triad (Confidentiality, Integrity, and Availability).

Ask a pentester the same question and they will say it is domain administrator.

Why is that?
Malicious actors don’t know how an organization fully operates.

We need to turn our SOC’s biggest weakness into its biggest strength: blindspots.
Attackers don’t know what will happen when they run a command for the first time in an environment.

This presentation will explore creating checkpoints at key environment operations for attackers, weaponizing the ambiguity of how environments operate. Turning their actions against them, instead into high fidelity canary token detections facilitating automatic response.

Securing the software supply chain across a large enterprise is a gargantuan task. To solve this problem, enterprise security teams often create established lists of “allowed” components that their developers can choose to use as direct dependencies. These lists are created by analyzing both the components themselves and their transitive dependencies. The general consensus is that this practice keeps vulnerable components out of developer ecosystems and reduces downstream risk.

But contrary to popular belief, these vetted component lists don’t improve the security of the software supply chain in actual practice.

In this talk, we’ll explain:

-The common mistakes process implementers make that introduce vulnerabilities
-How application build tool behavior and dependency install plans are the catalyst for insecure applications
-What teams can do to understand build context, harden their process, and avoid introducing new vulnerabilities