GhostAction Is Back: A Fake 'Security Audit' Workflow Hit 345 Repos in One Day. The Exfil IP Is Now in Our Feed.
On October 8, someone logged into two GitHub maintainer accounts that were not theirs and pushed a workflow named "Security Audit" straight to the default branch of 345 repositories. The workflow did the opposite of what it said: it collected every secret the repository's Actions could reach, plus any credential ever committed to its history, and posted them over plain HTTP to one IP address. StepSecurity, which documented the wave on October 9, calls it the return of GhostAction, the campaign first reported in September 2025.
As of today, that exfil address and six related indicators are in our feed. Here is what happened, what to search your own organization for, and exactly what our feed does and does not carry.
How the October wave works
The first account pushed the workflow to 27 repositories starting at 13:20 UTC. Eight hours later, a second account pushed it to 318 repositories in a 16-minute window, 21:10 to 21:26 UTC. That is not a person clicking. That is a script with a list.
The workflow file goes by one of three names: security-audit.yml, github_actions_security.yml or security-check.yml. Its job names are "Security Audit" or "Github Actions Security," and one variant has a step called "Prepare Cache Busting." It triggers on manual dispatch and on any push to any branch or tag, so the very commit that installs it also runs it.
The detail that matters most is the checkout depth. The workflow fetches the full git history, not just the latest commit. That means a cloud key someone committed in 2022 and deleted a week later is back in scope. Deleting a secret from the code was never the same as rotating it, and this campaign collects the difference.
The stolen material goes out by plain HTTP POST to 193.32.204.199, on port 80 and on port 3000 at the path /api/workflow/receive. The requests carry campaign markers in the query string, c=monami and c=new, and the body wraps harvested AWS-style keys between the strings AKIA_CTX_START and AKIA_CTX_END. If you log egress from your CI runners, those strings are what to look for.
The counts disagree, and that is fine
StepSecurity counted 345 repositories hit on October 8 and, in a code search the next day, 378 repositories with the workflow live on the default branch, before counting forks. Socket reports something much larger: more than 500 accounts committing the workflow to tens of thousands of repositories since October 7, with 279 forks carrying the file.
Those numbers are not necessarily in conflict. One is a count of injections in a measured window; the other counts every account and repository touched over a longer span, forks and all. We report both and lean on neither. For a defender the number that matters is one: whether the workflow is in your organization.
The maintainers are victims
Every one of these pushes came from a real maintainer's account. Those people had their credentials stolen; they did not attack anyone. We do not name them, and we do not put their accounts or repositories into our feed. Blocking a victim's repository protects no one and punishes the person who already lost.
What to do today
Search your organization's repositories for the three file names above, and for commits titled "Add security audit workflow," "Update security audit workflow," "Add security check workflow," "Add/Update Github Actions Security workflow" or "Trigger security scan." GitHub code search across your organization finds the files in seconds.
If you find one, assume every secret that workflow could reach is gone. That means the repository's Actions secrets, any organization secrets exposed to it, and every credential that ever appeared anywhere in the repository's history. Rotate them. Then look at your cloud provider's logs for those keys being used from unfamiliar addresses.
Block 193.32.204.199 at egress, especially from build runners. A CI runner has no business talking to a bare IP over plain HTTP.
Then close the door it came through. Require pull requests and review on default branches, put the .github/workflows directory under CODEOWNERS so workflow changes need a second person, set the default GITHUB_TOKEN permission to read-only, and require hardware-backed two-factor for maintainers. The attacker here never needed a vulnerability. They needed a password and a branch with no review.
What our feed carries, stated precisely
We ingested seven indicators today, all under source manual-batch-ghostaction-2026-10, each one written and then read back by primary key before we counted it as landed (7 of 7 verified).
The current wave: the exfil IP 193.32.204.199 at confidence 90, and the two exfil URLs with the c=monami and c=new markers, also at 90. The IP ships in our default ips.csv and clears our own edge shield's 80 floor.
The 2025 wave, from StepSecurity's historical list: 45.139.104.115 at 80, 170.39.218.2 at 75, the hostname bold-dhawan.45-139-104-115.plesk.page at 80, and carte-avantage.com at 75. The two legacy IPs are older infrastructure that may have been reassigned since, which is why they score lower; 170.39.218.2 sits below our edge shield's floor, and a subscriber pulling with min_confidence=80 will not get it. That dial is yours. For the Plesk hostname we fed the exact host only. The parent domain belongs to a hosting platform and must never be blocked wholesale.
This is not a detection lead, and we will not dress it up as one. These indicators entered our index on October 11, from StepSecurity's research published October 9. The single earlier trace in our corpus is block coverage, not sight: the 2025 C2 at 45.139.104.115 falls inside 45.139.104.0/24, which Spamhaus DROP listed on February 26 and our feed has redistributed since. Our own edge also blocked two other addresses in that /24 on February 7. A defender pulling our feed was covered for that address range, but we never saw this indicator before the researchers named it. The credit for finding GhostAction belongs to StepSecurity, Socket and the researchers before them.
Where else this applies
GhostAction is the same play as the Shai-Hulud worms and the stolen-developer-credential attacks we have tracked since our Pattern 38 work: steal one identity that a build system already trusts, then let the build system do the stealing. No vendor ties these campaigns to one operator, and nothing in our corpus links their infrastructure, so we call them siblings in method, not the same actor. The lesson carries across all of them. Your pipeline trusts whoever can push. Make sure that is a short list, and that a second person sees every change to the files that run with your secrets.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=ghostaction-returns-fake-security-audit-workflow-exfil-ip-in-feed
Comments