Compromise Splunk for AWS Privilege Escalation

What this lab covers

You gain access to a Splunk deployment, use its supported extensibility to obtain execution on the underlying host, and recover the credentials it stores for the cloud environment it monitors.

The uncomfortable idea in this lab is that security tooling is attack surface. Defensive platforms are given wide read access by design, are trusted implicitly, and their compromise is rarely modeled by the teams that run them.

It is rated intermediate and suits security operations engineers as much as testers. If you run a SIEM, this is what it looks like from the other side.

How monitoring platforms become attack paths

Splunk is extensible through add-ons, which are packages that can include scripted inputs. Running code is therefore an intended capability, not a vulnerability, and the ability to install an add-on is effectively the ability to run code on the host.

The credentials stored for data collection are the objective. To pull logs from a cloud environment, the platform must hold credentials for it, and those are stored in a form the application can decrypt because it needs them at runtime. Access to the host means access to the plaintext.

The access those credentials carry is usually broad. Log collection touches many services, so the identity is often granted wide read permissions across the account, and read access across an entire cloud estate is an excellent position from which to plan anything else.

How to detect this in your own environment

Alert on add-on and app installation, and on changes to scripted inputs. These are infrequent, high-privilege administrative actions, so the event volume is low and the signal is strong.

Treat the monitoring platform's own audit log as a monitored source, ingested somewhere the platform's administrators do not control. A SIEM that only monitors itself is not a control, because an attacker with administrative access can alter what it retains.

On the cloud side, baseline the collector identity. Log collection is repetitive and predictable, so that identity performing discovery, reading secrets or touching services outside its collection scope is a high-confidence indicator.

How to prevent it

Scope the collection identity to read-only access on exactly the log sources required. It is one of the easiest identities in the estate to over-permission, because granting broad read access makes onboarding new sources easier.

Restrict who can install add-ons and edit inputs, and separate that from day-to-day analyst access. Analysts need to search, not to deploy code.

Use short-lived federated credentials for cloud log collection rather than stored access keys, and place the platform behind your normal access controls. It should not be reachable from the internet, and administrative access should require the same controls as any production system.

Real-world context

Security and management platforms have repeatedly been used as pivot points in real intrusions, because they combine broad access with implicit trust. Remote monitoring and management tooling in particular has been abused to reach many downstream environments from one compromise.

The same logic applies to any agent-based platform with cloud integration, including vulnerability scanners, backup systems and cost management tools. Each holds credentials to the environment it inspects, and each is typically excluded from the threat model that covers the environment itself.

The pattern maps to MITRE ATT&CK T1072 Software Deployment Tools, T1552.001 Credentials In Files and T1078.004 Cloud Accounts.

Applying this at work

• Review the cloud permissions held by your log collection identity and reduce them to the specific read actions required.
• Restrict add-on installation to a small administrative group and alert on every installation.
• Forward your SIEM's own audit log to a destination its administrators cannot modify.
• Replace stored cloud access keys used by monitoring tooling with short-lived federated credentials.
• Add your security tooling to the scope of your next assessment, rather than treating it as part of the defense.

Frequently asked questions

Why would an attacker target a SIEM?

Because it holds credentials for every system it collects from, it usually has broad read access across the environment, and it is trusted implicitly. It is also where evidence lives, so control of it affects the defender's ability to investigate.

Is installing a Splunk add-on the same as running code?

Effectively yes. Add-ons can include scripted inputs, so the ability to install one is the ability to execute code on the host. Access control on that capability is the security boundary.

How should cloud log collection be authenticated?

With short-lived credentials issued through role assumption or workload identity federation, scoped to read-only access on the specific sources required, rather than long-lived access keys stored in the platform.

Do I need my own AWS account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS credential abuse and privilege escalation in full, and is assessed hands-on in a live AWS account.