The First 24 Hours of a Suspected GhostAction Compromise
A GhostAction alert can arrive through several different signals: a phishing report, an unexpected OAuth grant, a malicious workflow commit, or a developer machine contacting the threat IP. The first 24 hours should establish which of those signals are present and preserve enough evidence to decide whether the repository, the identity, and the workstation are separate containment problems.
OpenSourceMalware documented a second-stage chain that used .vscode/tasks.json, a fake public/fonts/fa-solid-400.woff2 payload, a cron job, and a fallback workflow. The October 26 update counted 1,230 repositories owned by 391 accounts with the full second stage and 1,279 repositories owned by 411 accounts with any tracked component. An incident lead should use that pattern to define scope, not assume every matching repository produced an execution.
0 to 2 hours: preserve and contain
Record the alert source and the exact account, repository, or endpoint that triggered it. Preserve the repository commit, task file, fake font, workflow history, OAuth grant details, endpoint process tree, and relevant network logs before remediation changes them. Isolate a machine only after capturing volatile evidence where policy permits.
Revoke active sessions and unknown OAuth grants from a clean device. Disable the compromised account's workflow-writing ability or repository access while the scope is established. If a threat IP or lookalike domain is in use, preserve the related mail, proxy, and DNS records and notify the identity owner without sending sensitive evidence to the suspected infrastructure.
The first decision is whether evidence supports execution. A malicious file in a repository is a lead. A matching task process, a cron entry, and a network flow to the threat IP are stronger evidence of execution. Keep those judgments separate.
2 to 8 hours: establish the account and repository scope
Enumerate every repository the account could write to. Search the full history for the hidden task, fake font, workflow names, and related commits. Check whether the repository was cloned or opened by a developer after the malicious change. Review GitHub audit records for token use, application authorization, organization changes, and new deploy keys or secrets.
Review the OAuth scopes repo, workflow, and read:org separately. Determine which organizations and repositories each scope could reach. A token may expose code, allow workflow changes, or reveal membership information even after the browser session is closed.
Check the endpoint for Node execution from a path containing fa-solid-400.woff2, scheduled jobs created around the same time, and outbound traffic to 193.32.204.199 on ports 8080 or 8443. Preserve the user's home-directory credential inventory without opening or printing secret values into the case notes.
8 to 24 hours: rotate and verify
Rotate credentials in dependency order. Start with cloud identities, repository-write credentials, package publishing tokens, and cluster administration. Then address SSH keys, AI-provider credentials, reused passwords, and lower-impact application logins. Perform the work from a clean device and verify that the old values fail.
Look for secondary persistence before declaring containment. The attacker could have created a new OAuth application, deploy key, organization membership, webhook, workflow secret, or service-account token. The primary malicious repository may be only the visible layer.
Use external observations as a time-bounded reference. On November 14, 2026, ZoomEye returned 2 observations for ip="193.32.204.199" and 1 for that IP combined with ports 80, 8080, or 8443. domain="my-github.com" returned 0. The broader queries returned 102 for domain="github.com" and 12,528 for app="GitHub Enterprise".
Those numbers support external scoping and a record of what was visible. They do not prove that a workstation executed the stealer or that a repository was infected. Keep the internal evidence separate in the incident timeline.
Recovery gate
Do not return the account or machine to normal use until the owner confirms the expected applications, tokens, repository permissions, scheduled jobs, and credential stores. Rebuild the workstation if execution cannot be excluded and the evidence needed for a confident conclusion is unavailable.
For the repository, verify that the malicious task, fake font, workflow, and related changes are gone from all branches and history that users can access. For the account, verify that unknown grants and tokens are revoked and that new credentials have been tested. For the endpoint, verify that the scheduled job and payload are removed or that the machine was rebuilt from a trusted image.
What completion looks like
Completion is not a single ticket closure. It is a linked set of findings across code hosting, identity, endpoints, and credentials. The incident owner should be able to identify the source of the alert, the affected accounts and repositories, the evidence for or against execution, the credentials that were rotated, the persistence checks that were performed, and any remaining uncertainty.
A well-run response may still have unknowns after 24 hours. The important outcome is that the team knows which unknowns affect containment and has assigned an owner and a verification step for each one.
