Greg Heon: I’m super excited to have Evan talk about some of the cool kill chains Armadin is finding. Today I want to go deeper, and focus on two big points.
One, these kill chains bind their findings together. Every finding along the way is reachable, exploitable, and has a blast radius you care about—something that actually hurts your company. Two, they have wildly different starting points and objectives. Armadin’s attacker can go after any type of IT you have, and that makes it special. So let’s kick off with kill chain number one.
Evan Peña: You asked me for a cool kill chain that goes from the internet into some kind of internal system. Most internet-facing systems are hosted in a cloud environment or a cluster—Kubernetes, AWS, and so on. This one traverses from an application into the web server, into a Kubernetes pod, and then breaks out into the cluster.
We started unauthenticated from the internet. There was a web application vulnerable to server-side request forgery (SSRF). In this case, an HTTP header could be manipulated to point the server at an arbitrary URL. That URL was an internal API endpoint that isn’t reachable from the internet, but it is reachable from that server. By manipulating the header, we could call that internal API and use its methods.
The API itself—a workflow engine—didn’t have anything super interesting method-wise, but it was vulnerable to a remote code execution 2025 CVE. We used the SSRF to reach the internal API, crafted a proof of concept for that CVE, and got remote code execution on the API endpoint. That SSRF turned into an API RCE, and it landed us in a Kubernetes pod.
It doesn’t stop there. On the pod, we did reconnaissance: what’s there, what are the namespaces, the APIs, secrets, and databases. There was a database on the pod, and you’d be surprised because there were service accounts stored in it. We pulled back database credentials in clear text, and those credentials had overly-permissioned access.
From that privileged container we were able to mount the host operating system of the cluster, break out of the pod, and get access to the Kubernetes cluster, which was part of an AWS tenant. From there we could reach other pods and cloud accounts with access to other systems.
So this chain went from SSRF at the application layer, to an internal API endpoint, to a pod, to service accounts, to the whole cluster, and to other pods. It was chaining a lot of vulnerabilities into a major impact, including access to production data and databases.
Greg: That’s awesome. I think what’s unique about this AI paradigm is that so many products historically are breadth-first. They look at a single type of IT and tell you maybe it’s vulnerable, in the best case that it’s exploitable. What I love about Armadin’s kill chains is that every time we reach and exploit something, we start looking outward again. We find the next best target, sometimes the next ten, in parallel.
SSRF on the internet isn’t good, and it should be fixed. But is it something you would keep the IT team late to fix? For most companies, no. But when you can show that SSRF means production data gets stolen—all in the span of a wandering AI attacker over hours, or minutes with the context we have—that changes things.
Evan: Exactly. Most people stop at “SSRF, it’s vulnerable, we proved it, let’s screenshot it into the report.” But what happens from there? Without going further we’d never have found the vulnerable API endpoint, the clear-text database credentials, the over-permissioned service account, or the pod breakout.
The way we measure risk is tailored for exploitability and impact. Here exploitability was very high (easy, unauthenticated SSRF) and the impact was very high because of the full chain. If we’d landed somewhere with no access and no usable methods, it’d have been low-to-medium impact and a totally different risk rating. That tailored, per-customer, per-finding rating is what lets you prioritize remediation.
And on remediation, the guidance goes further than “fix the SSRF.” Don't store clear-text credentials in databases. Patch the API endpoint vulnerable to the CVE. There are multiple points in the chain you can cut to sever the whole sequence.
Greg: Right. And customers treat these kill chains like security incidents. We have no way to know their intent. We’re preparing them for what’s coming with AI. They're not throwing this on the backlog as another tool finding. They’re keeping people late to fix it today. And they have options: fix the code, tighten permissions so the API isn’t reachable, or just put authentication in front of it. There are multiple ways to remediate, depending on the use case, and we help guide them to the path of least resistance.
Customers treat these kill chains like security incidents. We're preparing them for what's coming with AI.
Evan: One more point on the RCE. The CVE had some public POCs, but the LLM had enough context from pre-training and the internet to craft a custom POC in just a minute or two—even for a zero-day. Then we test it in a lab environment to make sure it’s stable. Honestly, it’s often more stable than some of the POCs I’ve seen on GitHub.
Greg: It raises the floor for what anyone can do. The script kiddie now builds their own exploits. Everyone feels like a badass hacker. I’m curious whether the more sophisticated adversaries adopt the same techniques. They have bosses, deadlines, and bureaucracy, but I expect tactics across the whole spectrum to converge on what LLMs can do.
Greg: So far everything’s been from the internet and outside-in. But that’s not the only way Armadin operates. We’re big believers in assumed-breach testing and deep web-app testing. Let’s bring an assumed breach to life.
Evan: With kill chain one, a lot of external apps land you in a cloud environment. But what about the corporate environment? There are basically four ways a corporate environment gets breached:
However you get breached, the real question is: what’s the impact? Can someone reach your crown jewels, escalate privileges, or move laterally? In the next chain we reached an actual OT environment.
Greg: This kill chain starts from an assumed-breach position. Think of a sales rep downloading the wrong attachment, and suddenly an adversary has access to a domain-connected computer on the corporate network. This is a Fortune 100 company that really cares about the security of its operational technology (OT). Can we reach it and show it’s at risk? It’s a story of impact from an assumed breach, in a very different domain.
Evan: We started with a low-privileged domain account and an initial foothold, then looked around. We found a relatively old server, a Windows Server 2019 box that’s vulnerable to Print Nightmare, the critical CVE from 2021. So it’s an OS about seven years old and a CVE about five years old. That let us drop a payload, run it on the box, and make ourselves the local admin.
On that server there was a database running locally—not exposed to the network, only visible on the host. It looked like a building management system (BMS) database, because we recognized product names. It had operator credentials, such as usernames and password hashes. We did a bunch of work trying to crack the hashes before realizing the passwords were stored in clear text right next to the hashes. We logged into the BMS application hosted on the same endpoint, and from there we could see sensor data across different OT networks and protocols.
Greg: In my mind this is a story of reachability. OT is almost never secure on its own. These are long-lived, expensive capital investments. The best you can usually do is make it not reachable. How do you make sure that when the sales rep clicks a link, someone in China can’t reach your OT? Here we found a path, and we found it fast.
Evan: The real way to separate OT is physical, like air-gapping, where you have to walk in. In this case the BMS managed things like HVAC or power for OT buildings, and it needed to be reachable by the people in the corporation who manage those buildings, for convenience instead of walking in each time. Convenience versus security. You trade one for the other. That reachability from corporate was our route into OT.
After exploiting Print Nightmare, we did what we always do: try to get more credentials. There was an exclusion folder for the AV/EDR with Microsoft Defender, and notably it was an exclusion folder set up for another security product, so its executables could run without AV blocking.
When you’re writing DLLs or exploit code, you run them from the exclusion folder so they slide past. We ran a payload there that pulled back Kerberos tickets and a service account. That particular thread was a dead end, but it shows that kill chains aren’t linear. They branch. The service account yielded nothing, but the BMS route yielded everything.
Greg: That’s notable: a cybersecurity tool leading to an exclusion configured in a cybersecurity tool, set up so a different cybersecurity tool could run. All living in the environment as the attacker, completely undetected.
Evan: The customer asked, “We’ve done annual pen testing for a decade. Why haven’t we seen this before?” The answer is scale and coverage. An annual pen test finds the one path of least resistance in a two-week window, writes it up, and shows the major impact. But what about the other paths, the other old systems that reach the same goal?
We’re in a new era. We can now cover the entire attack surface—external, internal, whatever endpoints you have—at a completely different speed. You’re going to uncover more paths than ever, and you’ll see an uptick of old systems, lots of CVEs and zero-days. Severing these chains goes beyond patching a system. It’s the network architecture misconfigurations you can leverage.
We're in a new era. We can now cover the entire attack surface, external, internal, whatever endpoints you have, at a completely different speed.
Greg: Before, if you hired a pen test product, you got breadth-first. It doesn’t go deep, so you talk yourself out of Print Nightmare being critical: “not internet-exposed, network is segmented.” It drops down your list and gets fixed slowly, or never. Six, seven years, way past a normal SLA.
This is a new world where we find all paths all the time. Our AI goes depth-first, taking the discipline and tradecraft of the best red teamers, forking in parallel, exploring more paths, then compressing massive attack data into findings, kill chains, and per-finding remediation guidance.
Evan: And you'll notice in this chain we stopped at OT. The goal was: what routes and permission misconfigurations get you access to an OT account? Ideally OT uses a different identity than corporate. Not always, but it should. What happens after that? Most of the time we stop at OT, and a specialized expert team comes in, because it's a very sensitive environment. What are your thoughts on assessing OT in this new AI world?
Greg: It’s on the minds of a lot of large-enterprise customers with real OT footprints. As AI on offense has ramped up, everyone’s asking “is this safe?” I like that we field the very best attacker in the world and customers are fully in control of it. They set the scope and engagement objectives, and we tell them all paths in, all the time. For OT the most important thing is reachability.
There are two other OT stories I emphasize. One is OT-on-the-way, mostly an IoT story. The smart thermostat with no EDR is a wonderful pivot point for OT on the way to a different objective, like the CEO’s emails. And the other is safety. Armadin runs safe attacks in real environments. Safety’s top of mind.
We just saw the news that OpenAI hacked Hugging Face, and Anthropic announced a few days later that they’d breached different organizations testing cyber models. We’ve focused hard on safe AI cyberattacks from the beginning, and that’s what lets us test OT systems safely.
Evan: One hundred percent, it’s a big priority.
Contributors: Armadin expert red teamers have years of experience in the world’s most critical environments, helping to build the Ultimate Attacker. Special thanks to Andrew Oliveau and Nick Cerne for contributing to this engagement.
Pressure-test your organization’s security in a safe, controlled setting: request a demo.
.svg)
.svg){kind=icon}
.svg)
.svg)