flexorium

We appreciate this information you share in the open

Nice! very useful

That’s definitely part of the solution to limit the risk, but it does not eliminate it. That’s exactly something the tool demonstrates very well. If you can exploit , you can gently ask OIDC to mint you access on the fly. That’s what I call “dwell mode” where you hang for say 1 minute and you perform arbitrary thing with the OIDC access. So yes with short lived creds there’s no “offline access” and if leaves more traces but still.

Thanks! I got tired of talking about it to defenders. I wanted to talk to Red Teamers too and SOC / detection engineering people. I wanted to build a tool that someone can just have the CISO try it directly.

Absolutely not. The same TTPs apply almost 1-to-1 for Insider Threat scenarios. We've built the Deciduous Attack Trees (shout out to Kelly) for insider threats last year. It overlaps. So either you start with Initial Access that's purely public and pivot deeper or you already have a modest foothold (like intern with read only access) and off to the races.

OP here, mini AMA.

Two years ago today, our small research team open sourced poutine, a SAST scanner for CI/CD pipelines (very similar to zizmor, but written in Go and customizable using Rego DSL). It finds the vulnerabilities in your build pipelines. As all security engineers know, running SAST and filing a JIRA ticket leads to nowhere.

Some weeks ago TeamPCP came on the scene and most were shocked to see the blast radius starting with Trivy then LiteLLM, KICS, etc. Trivy got pwn'd using textbook "pwn request".

I've been building SmokedMeat for the past 5 months to level the playing field. It's a Red Team framework for CI/CD pipelines. You scan a GitHub org workflows, pick from a menu of exploitable pipelines, you are guided through an exploitation wizard, wait… and you're in post-exploitation. Secrets already exfiltrated from runner process memory are in the Loot stash, ready to pivot into cloud accounts, private repos, and more. Live attack graph in the browser.

To try it: git clone https://github.com/boostsecurityio/smokedmeat.git cd smokedmeat make quickstart

Then you target the whooli GitHub org (https://github.com/whooli) a CTF playground to exploit (hint the final flag is in a Google Cloud Storage Bucket)

Happy to answer questions about the ethics, architecture, implant design, or CI/CD attack techniques.

We're pretty excited to finally talk about this new TTP.

I’m somewhat surprised to see that they use a KVM to switch between back and forth between a JWICS and SIPRNET. I would imagine it’s a special KVM as it’s essentially bridging the airgap between the two.

I’m guessing that’s the product in question: https://www.vertiv.com/490454/globalassets/products/monitori...

In the audit log of the organization you can see an event, but by that time you have lost visibility into what the attacker really executed.

So a malicious tag payload (stage 1) will still remain in events, but Stage 2 will be lost completely (only the fact that log was deleted) and that would not leak any what really was executed with like `curl | bash` could be silent

Most likely the end goal is to backdoor the final artifacts, so one could diff, I guess.

When people think about Supply Chain security, they generally think of SBOM and vulnerabilities in your direct and transitive dependencies.

But most people are completely blind of vulnerabilities in the Build Pipeline of those same dependencies. The SLSA framework considers those https://slsa.dev/spec/v0.1/threats#build-integrity-threats to some extent. And OpenSSF aficionados know, but it's still niche.

I like to think of those as a parallel universe! An orthogonal plane of vulnerabilities that are beneath the surface and completely independent of vulnerabilities into the source code of the project itself. Basically never tracked as CVEs... Those can be nested deep, deep, in a transitive build dependency 5 levels down.