Introducing Aggressor Mode

Vulnerability management backlogs are full of findings that never get fixed. Not because the findings are wrong. Not because the teams receiving them don't care. But because a neatly categorized list of vulnerabilities rarely communicates what actually matters: what happens next.

The disconnect is simple. Vulnerability scanners find individual issues. Real attackers chain them. They don't file a report after discovering a single vulnerability and move on. They pull the thread — probing internal services, harvesting credentials, pivoting laterally — until a convenience feature in your application becomes the entry point to your entire database.

Today, we're releasing Aggressor Mode to close this gap.

What Is Aggressor Mode?

It is a new operational setting that transforms Shinobi into an unrelenting adversary. When activated, Shinobi doesn't stop at discovering the first application vulnerability. Like an experienced penetration tester, it shifts into a post-exploitation mindset — chaining vulnerabilities, following lateral movement paths, and demonstrating the maximum realistic impact of every flaw it finds.

The mode activates Shinobi's tactical expertise: its understanding of how vulnerabilities relate to one another, how environments are structured, and how a patient attacker navigates from an initial foothold to a high-impact objective. It explores multiple attack paths in parallel, mapping not just the single most obvious route but every viable chain it can construct from the weaknesses it discovers.

The result is a penetration test report that doesn't just list what's broken — it tells the story of what an attacker would actually do. And stories, unlike spreadsheets, drive action.

Shinobi in Action

To demonstrate the capabilities of Aggressor Mode, we put it to test against a realistic environment containing multiple attack paths.

The target was a complex cloud-hosted employee management platform to handle onboarding, benefits enrollment, and internal communications. The application tier runs on EC2 and handles authentication, messaging, and a link preview feature that generates rich preview cards when a user pastes a URL into a conversation. User accounts, employee records, benefits data, and message history all live in a PostgreSQL database on RDS, sitting in a private subnet with no public accessibility. The application retrieves its database credentials from AWS Secrets Manager at startup. We gave Shinobi a standard employee-level account on the application to test: how far can you go?

The Attack: Anatomy of a Chain

What follows is a walkthrough of the attack paths Shinobi identified and exploited in Aggressor Mode — completed in under seven minutes.

Step 1: The Entry Point — Server-Side Request Forgery

Shinobi began where any attacker would: examining application functionality. The link preview feature in the application's messaging module immediately drew its attention. When a URL is pasted into a conversation, the server fetches it to generate a preview card — pulling the page title, description, and Open Graph image.

Shinobi identified the SSRF vulnerability in this feature by submitting a URL pointing to infrastructure it controlled and confirmed the application was making the request directly.

It then tested internal addresses and found no URL validation or allowlisting in place. The application would dutifully fetch whatever it was given — including addresses on internal networks and, critically, the AWS metadata service at 169.254.169.254.

Step 2: Querying the Instance Metadata Service

With the SSRF confirmed, Shinobi directed the application to query the EC2 Instance Metadata Service. Because the instance was configured with IMDSv1 enabled (http_tokens = optional) — a common default in Terraform deployments and older infrastructure — no session token was required. A simple GET request was all it took.

Shinobi enumerated the metadata tree methodically, identifying the IAM role attached to the instance and retrieving the temporary security credentials associated with it: an Access Key ID, Secret Access Key, and Session Token.

At this point, Shinobi had the ability to make AWS API calls as the application's EC2 instance. The SSRF had become a foothold in the cloud control plane.

Two Paths Diverge

This is where Aggressor Mode demonstrates its value. Rather than following a single exploitation path, Shinobi identified and explored two distinct attack chains. Both paths branched from the metadata service but only one of them arrived at the production database.

Path A: The Cloud Control Plane

Step 3a — IAM Credential Abuse. Using the stolen temporary credentials, Shinobi began enumerating what the IAM role could access. The role wasn't an administrator — it was scoped to specific services. But it had more permissions than the application actually needed at runtime. Specifically, rds:DescribeDBInstances gave Shinobi the full metadata of the production database: its endpoint, engine version, VPC placement, and security group configuration. The application never calls this API — it already has its connection string. But for an attacker, it's a complete roadmap.

Step 4a — Secrets Manager. The role also had secretsmanager:ListSecrets and secretsmanager:GetSecretValue scoped to Resource: * rather than the specific secret ARN the application uses. Shinobi listed all available secrets, identified the database credential secret, and retrieved the production database username, password, host, and port. The credentials had been exfiltrated entirely from outside the VPC, using nothing but the AWS API.

But this path turned out to be a dead end as the database was located in a different subnet and public access was disabled. Even though the database credentials were extracted, there was no easily available route to use them.

Path B: The Localhost Backdoor

This path is where things got interesting.

Step 3b — User Data Exposure. Shinobi used the SSRF to query the instance's user data endpoint at 169.254.169.254/latest/user-data. The startup script — intended to bootstrap the application — contained hardcoded references to internal architecture, including an internal admin API running on port 8080 on the same instance.

Step 4b — Unauthenticated Admin API. Shinobi directed the SSRF at http://127.0.0.1:8080 and discovered the admin API had no authentication. It was assumed to be safe because it was only reachable from localhost — an assumption the SSRF shattered. Among the exposed endpoints was /admin/query, a debugging tool that accepted raw SQL and had never been removed before the application reached production.

Step 5: Database Exfiltration

Through Path B, Shinobi used the unauthenticated admin API to execute SQL queries directly against the production PostgreSQL database, reflected back through the link preview feature. It enumerated every table in the schema — employees, benefits_enrollment, salary_records, ssn_vault, performance_reviews — and demonstrated the ability to extract employee PII, salary data, and social security numbers.

The link preview feature had become a window into the entire production database.

The Attack Paths Explored

Why This Matters

Aggressor Mode exists to make the collective impact of vulnerabilities visible. When a stakeholder sees that a "high-severity" SSRF led to a full database breach in under seven minutes — with employee social security numbers as proof — the conversation changes. Priorities shift. Budgets move.

This is what Shinobi's Aggressor Mode delivers: not just a list of what's wrong, but an unambiguous demonstration of what happens if it isn't fixed. It's the difference between telling someone their front door lock is weak and showing them a stranger standing in their living room.

Attackers don't stop at the first bug they find. Your penetration testing shouldn't either.

---

Ready to see what Shinobi's Aggressor Mode can uncover in your environment? Book a demo to experience vulnerability chaining in action.