GhostAction Phishing Campaign

What it is

OpenSourceMalware's write-up of a targeted phishing email from noreply@my-github[.]com ("[GitHub] New sign-in from Moscow, Russia"). It is the GhostAction operators' move from malicious Actions workflows to phishing maintainers. The domain resolves to 193.32.204[.]199, the same server that receives the stolen CI/CD secrets. The lure URL was https://my-github[.]com/SDRVuhYw.

How it works

• The site is a reverse proxy of real GitHub pages, not a static clone. POST /session sends the login and password to the attacker origin. GitHub hostnames are rewritten to github., api., docs., support. and collector.my-github.com.
• An injected script waits for an authenticated-user avatar. It then starts an OAuth device flow with client ID Ov23ctrqCqZ79UaYKwyq and scopes repo+workflow+read:org. It loads /login/device, fills in the user code, adds authorize=1 and posts the approval through the victim's proxied session. The victim never types a code or approves anything knowingly.
• The token goes to https://my-github.com:8443/t?value=<token>&user=....
• A second script, /s/6b159fd2…23f2.js, polls for JSON containing redirect_url and assigns it to top.location.href. This gives the operator per-session control over where the victim lands.
• The workflow scope fits the campaign's next step, committing files under .github/workflows/.

What to do

Block and hunt:

• my-github.com and *.my-github.com
• 193.32.204.199
• TCP/8443 to the campaign domain
• the TXT record google-site-verification=gp-lwE_I_dYU0TINi0fb4XEB0QpjviIXSPE69Kiyyew
• noreply@my-github.com
• the subject fragment "New sign-in from Moscow, Russia"
• the lure IP 95.214.27[.]108 in message bodies. It is lure content, not attacker infrastructure: RIPE places it in Bulgaria.

Static and telemetry markers: vh_device cookie, /vh_beacon, console strings VH1 ok, VH3 code, VH4 auth, VH5 TOKEN.

If someone opened the link and may have entered credentials or a code:

1. Preserve browser, DNS, proxy and endpoint telemetry first.
2. From a clean device, revoke sessions and tokens and reset credentials.
3. Review SSH and GPG keys, OAuth and GitHub App authorizations, and repo and org activity.
4. Remove any OAuth grant for client Ov23ctrqCqZ79UaYKwyq.
5. Org owners should review OAuth app access policy.
6. Check reachable repos for unexpected workflows, unsigned direct pushes, modified release assets, new deploy keys, changed webhooks and trigger-only commits.
7. Rotate package-publishing, cloud, deployment and CI/CD secrets. Deleting a malicious workflow does not invalidate secrets already copied.

If you received a similar message, keep the original .eml file. Forwarded copies lose the headers.

Caveats

• The HAR proves the password and a one-time code were sent to the attacker origin. However, the OTP was posted to /sessions/verified-device, and no POST of the /sessions/two-factor form appears.
• The HAR shows no /login/device/code, token or 8443 requests. The OAuth automation is confirmed from source only; successful token issuance and receipt are unverified.
• Redirect behaviour is mutable. URLScan saw a Rickroll on 2026-10-09, then github.com on 2026-10-10. Scanner results alone cannot clear the URL. The captured redirect response was HTML, not the JSON the controller expects.
• The Amazon SES eu-west-1 delivery inference rests on a retained message-ID format only, and the original authentication headers are missing.
• The HTML's meta verification token Apib7-… also appears in an unrelated PDF, so it is not a reliable pivot. The DNS token is the better one.
• my-gitlab[.]com is an unconfirmed watchlist item.
• Phishing is not proven to have caused earlier GhostAction compromises.
• In the one victim they worked with, an additional MFA challenge stopped escalation, though the attacker did log in.