Phishing is still one of the most used and abused techniques to gain initial access to infrastructure, get credentials or spread malware. Sometimes two factor authentication (2FA) is heralded as a solution, which can bring an end to this type of attack. While it is true that it can defend the infrastructure against simple phishing or some cases of credentials reuse, I will demonstrate that it is not enough for a determined attacker.

What happened?

It all starts as a usual phishing attack, but there are a few differences. The phishing website responds the same as a legitimate login page, including prompting for a 2FA token, the attacker steals not only the victim’s credentials, but session as well, and the phishing infrastructure carries out actions with the victim’s stolen session immediately.

The phishing site responses and session stealing are done by Evilginx2. It acts as a man-in-the-middle reverse proxy between a victim and a real login server. It receives HTTP requests for the attacker’s domain afaf.red, makes the same requests to github.com and passes each response from github.com as if it was coming from afaf.red. A more in-depth explanation can be found in this video.

After a victim successfully logs in using their username, password, and 2nd factor, the attacker gets their session cookies. This is a prompt for a set of custom python scripts and a headless browser running on a machine called burmy. These automatically get 2FA recovery codes, which can be used instead of a proper 2nd factor and screenshot GitHub dashboard as a logged-in user for reporting purposes. Then they issue a new Personal access token with full privileges, which grants access to GitHub API, so any following activity does not have to be done by a headless browser. Lastly, they add new SSH and GPG keys using the new Personal access token.

Using the SSH and GPG keys, the attacker can, for example, look through the code and make verified changes. With the Personal access token, the attacker has full access to the victim’s Github API, which means they have even more control with capabilities like issuing new SSH and GPG keys, pull requests, or even enterprise level administrative. There is also a tool called ghorg, which can use this token to automatically and quickly dump all repositories.

The video also showcases a manual takeover, by inserting the stolen session cookies into their browser and interacting with the website as a logged-in user directly.

Just to be clear, this is not a Github vulnerability. This is a result of a new type of phishing, which can steal sessions and showcase how such access can be used. An attacker could do similar damage in any other application.

Other possible attacks

Since these attack methods are quite general, an attacker can use a headless browser to do any number of actions based on the application that is under attack. In general, after successful phishing, the attacker possesses the user password, a valid session, and in some cases, these can be leveraged to either create a new 2FA token or just dump 2FA recovery codes the same way as in the GitHub demo. At that point, they have full control over the account.

But even with limited control, if the victim has access to some sensitive data, the attacker can in general automatically download it almost immediately after a successful session stealing.

If the attack was focused on an email account, they could immediately delete the “New login to the application” message the server sends, dump all of the emails and send another wave of phishing on behalf of the user before they even realize what is happening.

Countermeasures

Even though this is a newer method of phishing, it is still just phishing. Usual countermeasures apply here as well:

• Spam filtering
• Users always checking the URL
• Monitoring of similar-looking domain names
• Keeping the user’s guard up

This type of attack differs from typical phishing only by login being far more realistic than hand-crafted one and by proxying all of the requests, so in some capacity, it is detectable on the server-side as well.

If the organization has monitoring, they can look for successful logins of multiple users coming from a single new IP. However, this can lead to some false positives anytime several users use a shared WiFi, like at a conference. Furthermore, with some additional work, even this protection can be circumvented by attackers using multiple proxies.

Evilginx2 and Gophish in their default setting send SMTP and HTTP headers which can be easily detected as well.

The most certain way to prevent this attack is to use U2F 2FA, such as a physical token. This is because in that case, the server name is checked automatically, and since an attacker uses a different one 2FA will fail. However, outfitting each employee with a physical token could be very costly and hard to implement.

When researching this topic I noticed a notable lack of freely available resources. I understood it better when I considered disclosing what I learned.

I do not want this to be used in any malicious way, which is why I will not publish this solution as a ready-made code, even though I would like to help the open-source community with some new spin on some of these tools.

My goal is to start a conversation about the capabilities of a modern infrastructure and countermeasures that can be instated to prevent such attacks.