
Ghost Action: The Silent Workflow Heist
The GhostAction campaign targeted GitHub workflows to steal sensitive data. Attackers injected malicious workflows into public repositories, which then exfiltrated credentials and tokens to attacker-controlled servers. The incident compromised hundreds of repositories and exposed thousands of secrets, including API keys, package manager tokens, and cloud access credentials.
Indicators of Compromise
IPv4 (1)
45.139.104.115Notes
<div class="content-body"> <span class="content-title">CONCLUSION</span> <p class="content-description">The GhostAction campaign shows that attackers can move fast, reach deep, and steal critical secrets from developer ecosystems — often before anyone realizes what’s happening. What started as a single compromised GitHub account quickly expanded to hundreds of repositories, across multiple languages and package registries. Even though no signs of malicious package releases have emerged so far, the damage potential was real: credentials that provide access to cloud systems, package publishing, databases, and more.</p> <p class="content-description">This incident proves two things: one, CI/CD workflows are a strategic target and can become a weak link; two, detection, response, and remediation speed are vital. The developers’ rapid reversal of malicious changes, the alerts to registry security teams, and secrets’ rotation likely prevented an even more damaging outcome. But the campaign should serve as a wake-up call: organizations must treat secrets and workflows as high-risk assets. Strengthening process controls, limiting permissions, improving monitoring, and embedding security across the software supply chain are not optional — they are essential.</p> </div>
Mitigation
<div class="content-container"> <span class="content-title">T1190 – Exploit Public-Facing Application</span> <div align="left"> <table> <colgroup> <col> <col> <col> </colgroup> <tbody> <tr> <th>ID</th> <th>Mitigation</th> <th>Description</th> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1048">M1048</a></td> <td><a href="https://attack.mitre.org/mitigations/M1048">Application Isolation and Sandboxing</a></td> <td>Application isolation will limit what other processes and system features the exploited target can access.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1050">M1050</a></td> <td><a href="https://attack.mitre.org/mitigations/M1050">Exploit Protection</a></td> <td>Web Application Firewalls may be used to limit exposure of applications to prevent exploit traffic from reaching the application.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1035">M1035</a></td> <td><a href="https://attack.mitre.org/mitigations/M1035">Limit Access to Resource Over Network</a></td> <td>Ensure that all publicly exposed services are actually intended to be so, and restrict access to any that should only be available internally.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1030">M1030</a></td> <td><a href="https://attack.mitre.org/mitigations/M1030">Network Segmentation</a></td> <td>Segment externally facing servers and services from the rest of the network with a DMZ or on separate hosting infrastructure.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1026">M1026</a></td> <td><a href="https://attack.mitre.org/mitigations/M1026">Privileged Account Management</a></td> <td>Use least privilege for service accounts will limit what permissions the exploited process gets on the rest of the system.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1051">M1051</a></td> <td><a href="https://attack.mitre.org/mitigations/M1051">Update Software</a></td> <td>Update software regularly by employing patch management for externally exposed applications.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1016">M1016</a></td> <td><a href="https://attack.mitre.org/mitigations/M1016">Vulnerability Scanning</a></td> <td>Regularly scan externally facing systems for vulnerabilities and establish procedures to rapidly patch systems when critical vulnerabilities are discovered through scanning and through public disclosure.</td> </tr> </tbody> </table> </div> <span class="content-title">T1552-Unsecured Credentials</span> <div align="left"> <table> <colgroup> <col> <col> <col> </colgroup> <tbody> <tr> <th>ID</th> <th>Mitigation</th> <th>Description</th> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1015">M1015</a></td> <td><a href="https://attack.mitre.org/mitigations/M1015">Active Directory Configuration</a></td> <td>Remove vulnerable Group Policy Preferences.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1047">M1047</a></td> <td><a href="https://attack.mitre.org/mitigations/M1047">Audit</a></td> <td>Preemptively search for files containing passwords or other credentials and take actions to reduce the exposure risk when found.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1041">M1041</a></td> <td><a href="https://attack.mitre.org/mitigations/M1041">Encrypt Sensitive Information</a></td> <td>When possible, store keys on separate cryptographic hardware instead of on the local system.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1037">M1037</a></td> <td><a href="https://attack.mitre.org/mitigations/M1037">Filter Network Traffic</a></td> <td>Limit access to the Instance Metadata API. A properly configured Web Application Firewall (WAF) may help prevent external adversaries from exploiting Server-side Request Forgery (SSRF) attacks that allow access to the Cloud Instance Metadata API.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1028">M1028</a></td> <td><a href="https://attack.mitre.org/mitigations/M1028">Operating System Configuration</a></td> <td>There are multiple methods of preventing a user's command history from being flushed to their .bash_history file, including use of the following commands: <span>set +o history</span> and <span>set -o history</span> to start logging again; <span>unset HISTFILE</span> being added to a user's .bash_rc file; and <span>ln -s /dev/null ~/.bash_history</span> to write commands to <span>/dev/null</span> instead.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1027">M1027</a></td> <td><a href="https://attack.mitre.org/mitigations/M1027">Password Policies</a></td> <td>Use strong passphrases for private keys to make cracking difficult. Do not store credentials within the Registry. Establish an organizational policy that prohibits password storage in files.</td> </tr> <tr> <td><a href="https://attack.mitre.org/mitigations/M1022">M1022</a></td> <td><a href="https://attack.mitre.org/mitigations/M1022">Restrict File and Directory Permissions</a></td> <td>Restrict file shares to specific directories with access only to necessary users.</td> </tr> </tbody> </table> </div> </div>