5 critical lessons from the latest GitHub phishing campaign by Gitloker

Understanding the Gitloker Phishing Attack

Last week, a Chilean security researcher by the name of Germán Fernández encountered a phishing campaign by an attacker with the Telegram handle ‘Gitloker’. The attack employed four core methods:  

1. Account & Repository Compromise: Beginning in February 2024, the attacker(s) impersonated GitHub security team as well as the recruitment teams in phishing attacks to extract login credentials from users. The attacker was then able to gain access to GitHub user accounts using compromised credentials.  
2. Data Theft: The contents of the repository were, as explained by the attacker, cloned and removed from the repository.  
3. Repository Renaming & Messaging: After wiping the contents of the repo, the attacker renamed the repo and added a single README.md file, which contained instructions directing the victim to contact the attacker on Telegram.
4. Ransom Demands: On Telegram, the attacker demanded a ransom payment in exchange for the stolen repository contents.

Security and engineering teams are left trying to ensure that they’re not susceptible to this type of attack in the future. Let’s look at 5 key and actionable lessons we can take from the Gitloker attack.  

Lesson 1: Protect GitHub Accounts via MFA or Passkeys

One of the key lessons to learn from the Gitloker attack is the absolutely critical importance of implementing strong authentication methods to protect your source code management accounts. Robust authentication mechanisms can dramatically reduce the risk of unauthorized access and mitigate the impact of phishing attacks as a result. Let's explore a few options.

Multi-Factor Authentication (MFA)

MFA really needs no introduction. It’s rightfully recommended widely as a quick and powerful security win.  It can be configured by each user in the profile security settings page in GitHub.  

As a matter of fact, GitHub has been rolling out an MFA requirement over a year now, so there is no reason for active users to remain unprotected.  

Passkey Authentication

While MFA is effective, there has been innovation in the world of authentication over the past number of years in the form of Passkey Authentication. Passkeys eliminate the need for passwords, replacing them with a combination of cryptographic keys. Here is how it works:  

1. Enrollment: While setting up a passkey, a cryptographic key pair is generated. The private key is stored securely on your device, while the public key is shared with the authentication server.  
2. Authentication: When you attempt to log in, the server sends a challenge to your device. The device uses the private key to sign the challenge and send the signed response back to the server. The server verifies the valid signature using the stored public key and grants access.  

This may sound jargony and complex, but it’s really quite simple. Here is a great short video explanation.  

Passkeys are not only easy to implement, but they also come with several important security and operational benefits:  

• Resistance to Phishing Attacks (like this one!): Because there is no password to steal, phishing attacks become much less effective when using Passkeys.
• Convenience: No need to manage passwords across accounts and devices, reducing the likelihood of password reuse.
• Strong Security: The private key never leaves your device, making it resistant to remote attacks.  

GitHub recently introduced support for passkey authentication! On the heels of the Gitloker attack, now is the perfect time for developers and organizations to transition to Passkeys. Check out detailed documentation on Passkeys from GitHub.  

Passkey authentication is my personal preference – here is how it looks in GitHub.

Lesson 2: Managing Developer Accounts

Personal vs. Enterprise Git Accounts

Most modern software organizations allow users to bring their own GitHub accounts as opposed to using Enterprise Managed Accounts (GitHub docs), though there are serious tradeoffs to consider with each approach.

In the instance of the Gitloker attack, both personal and corporate emails are subject to the same risks. But it’s worth noting that organizations that allow personal accounts typically provide corporate access to those personal accounts, which expands the attack surface in this case.  

Let’s look at an example, below. This user has a @gmail account and a corporate @gitgoat.tools account (side note: GitGoat is an open-source project that provides DevOps teams with intentionally misconfigured assets and accounts to assist in testing misconfiguration prevention strategies).

In this example, Bill De Pipeline can be targeted via both email addresses. A successful attempt could potentially grant access to all resources that this account has access to. That includes “GitGoat” corporate assets!

Access via Corporate SAML

Using SAML ensures that even if you are using your personal account that you are authenticated in the corporate context. So, while you do need MFA, it’s critical to also have protection in the form of a corporate authentication process via SAML. We give GitHub their flowers in a few cases throughout this blog... but unfortunately GitHub only supports SAML for GitHub Enterprise customers, leaving many organizations without a critical security capability.

For example, the screenshot below shows the preferred organization settings to enforce both MFA on the GitHub account and SAML authentication in the corporate context. Hopefully the two authentication methods aren’t using the same passwords 😉.

Assuming a Successful Phishing Campaign, Can an Adversary Generate a PAT to Access Your Corporate Assets?  

In a positive update, GitHub requires users to go through additional SAML authorization in order to allow a personal access token (PAT) access to corporate assets. But have you considered the scenario in which an adversary re-generates an existing personal access token (PAT) that has already been authorized via SAML? In short, GitHub now requires the same additional SAML authorization when a PAT is regenerated. As promised, Kudos!

Lesson 3: Detecting & Mitigating Hardcoded Secrets

Leaked and stolen credentials continue to be a major contributor to high-impact attacks like the Gitloker attack. While the credentials used to carry out this attack were stolen by way of social engineering and phishing, there is a hugely concerning downstream impact of Gitloker now having the stolen contents and the entire git history of the compromised repositories. What if the git history contained API tokens? Or your cloud root account credentials? The attacker, using their stolen credentials, now has access to the corporate environment, the contents of your repos, and an ability to clone them.  

It’s critical to ensure that you implement tooling to identify all secrets in git history and prioritize them effectively. Since you can’t wave a magic wand and have all historical secrets removed, the depth of prioritization capabilities in your secret detection tool is key. For example, you may want to be able to prioritize validated secrets or a specific custom internal secret type or credentials to a specific set of assets in your environment. Your tools should help get you this granularity of prioritization to help you eliminate all secrets from the git history and prevent introducing new secrets.

Check out our blog on selecting a secret detection & mitigation solution.

Lesson 4: The Extent to Which Anomaly Detection is the Right Fit

Attacks like the Gitloker attack often illicit exploration of anomaly detection solutions. The attacker, after all, deleted all contents of the repository... something that could be considered highly anomalous.  

A few factors are needed to identify this type of attack, such as:

• Source IP address, although it is arguably prone to false positives with the introduction of Web IDEs and remote workforce employment in general.
• Correlation to the user agent, authentication protocol, and other metadata. Keep in mind that if the adversary has access to the audit log, all can be matched to avoid detection.
• Potential correlation to a branch protection bypass or repository renaming. You can see these events by looking at `repo.rename` or `protected_branch.policy_override` events in the audit trail.
• Evidence of the `git push –f origin main` (can be other branch name) unique event that shows that such risky command has been executed, that can potentially delete the history of all commits (hence, deleting all code).
• Attacks at scale require automation, which needs to make API calls to determine which assets to target, as well as `git clone` events that can allude to a source code exfiltration trigger. API calls are not recorded in the audit trail, but `git clone` events are. GitHub allows enterprise customers to stream API calls information to external systems.

So... do we need anomaly detection, or can this attack be identified in a deterministic manner?

I’d love to “sell” the anomaly detection dream here, but this attack can be easily classified with basic SIEM logic. Think about the following correlation rules, which can be used distinctly to detect such attack:

• Identify multiple repositories rename events by the same user – it doesn’t happen often, and you should be aware of it anyways.  
• Identify multiple `git push` or `protected_branch.policy_override`events from the same user across multiple repositories. You will need to ignore any usernames ending with `[bot]` and other service accounts, as they may actually need to push code frequently.  
• If you have correlation to identity provider logs, ensure that the users have a matching authentication activity with GitHub. If developers don’t use web IDEs, you can correlate to endpoint security system logs as well.

Lesson 5: Implement “Least Privilege” Without Upsetting Developers

Least privilege access is a controversial topic in the AppSec space given its obvious security benefits and its inherent ability to add friction for developers if handled poorly. The importance of implementing least privilege measures is clear in the example of Gitloker in that the attacker was able to leverage broad permissions to clone repositories at will and delete their contents thereafter. With better permissions management, the impact of the attack may have been contained.  

For example, developers can force push by default, unless a branch protection policy or a ruleset is configured to prevent a forced git push. Even if configured properly, developers with repository admin permissions can bypass such control. It means that permissions need to be managed from the enterprise level down to the branch level.  

Many organizations shy away from implementing least privilege as it can cause delays for developers who need quick access to a given repository to push code for a new feature they’re working on. If permissions take any significant amount of time, the developer gets blocked and none of us wants to be on the bad end of a pissed off developer.  

However, integrating nimble least privilege controls into the source code management (SCM) can both strengthen and simplify permissions management. Auditing and updating rules become easier, ensuring that rules remain in alignment with security policies. Going even further, you may want to leverage native integrations between your permissions management tool and your chat platforms like Slack or Team to facilitate self-service provisioning for certain assets to minimize delays and disruptions while maintaining full auditability and control.  

Takeaways from the Gitloker phishing and repo attack

The Gitloker phishing and repository attack was well orchestrated and impactful. It leveraged four methods to compromise its targets including account compromise, data theft, repo high jacking, and ransom demands.  

That said, there are practical steps that AppSec and DevOps teams can take to defend against similar attacks and limit their impact, should they occur. By implementing strong authentication methods like MFA and passkeys, thoughtful developer account management, hardcoded secret detection & mitigation, basic SIEM correlation logic, and thoughtful permissions controls, organizations can better protect their development environments and minimize the risk of similar attacks.

___

If you've made it this far, book a demo with me to learn more about how Arnica can help defend against this type of attack across Lesson 3: Secrets, Lesson 4: Anomaly Detection, and Lesson 5: Thoughtful Least Privilege