PhishinGit – GitHub.io pages abused for malware distribution

Introduction

GitHub has become a core part of the development ecosystem for version control and storage of personal projects, but also for large open-source codebases to be maintained. One other core feature of GitHub is that it has ability for users to create and host free static webpages for repositories. These use HTML, CSS, and JavaScript files directly from a repository and appear as github.io web pages. This can be used to showcase open-source pages and host content without requiring the purchase of domains and server hosting.

During CYJAX’s research, analysts observed several phishing pages containing fake Adobe CAPTCHA pages with sophisticated anti-analysis measures. Each of these were hosted on the github.io domain. Through further analysis, CYJAX identified that each site was part of a redirection chain from tracking links with ‘go’ subdomains. Once the displayed CAPTCHA was passed, the Browser-in-the-Browser (BitB) technique was used to open a fake Adobe-themed iframe download page. From here, users were urged to download an executable which appears to be a version of ScreenConnect.

This blog will explore this phishing campaign which CYJAX has titled PhishinGit, exploring how the phish works, its observed anti-analysis measures, and potential mitigations.

Technical Overview

By looking at the user account behind the observed phishing page, a GitHub repository titled “xlsxpreview” was identified, shown in Figure 1. This page contained a single index.html file which builds a fake Adobe CAPTCHA page in a one-line command as part of a HTML script. The use of a single malicious script to build the page could indicate that legitimate websites are compromised through an attack such as cross-site scripting (XSS) where this script is delivered. Alternatively, it may just act as an anti-detection and analysis measure.

The attack chain

As CYJAX discovered the phishing pages directly, the original initial access method is currently unknown. Through observing the redirection chains, it appears that infection began with victims clicking on a Pardot link. This is a legitimate service offered by Salesforce and is used as part of advertising campaigns to generate tracking links for marketing purposes.

When a user clicked on the link it either sent them to a subdomain of a legitimate website or in some cases, generated a Bing search which would direct victims to a webpage. Once victims landed on these pages, each contained malicious code which would force the user to a phishing page hosted on GitHub and controlled by the attacker. An example of this can be seen in Figure 2, with a de-obfuscated version of this script highlighted in Figure 3.

These webpages appear to act as intermediaries. This means that the threat actor can ensure that if GitHub take down the phishing page, it could quickly create a new one and only have to update the intermediary page. As such, if a user received the phishing link but did not engage with it, the intermediary allows it to still function. It would then send the user to a new malicious download page if the original one has been taken down. By abusing subdomains, this also acts as an anti-detection measure and allows the threat actor to hijack the existing reputation of the legitimate sites.

For the latest version of this campaign, CYJAX has identified several go[.]pardot links which sent users to go[.]cecocatalog[.]com. This is a subdomain of a seemingly legitimate website. The cecocatalog[.]com domain is over four years old and has been referenced legitimately by several other sites, including the much older cecosinks[.]com. From historic analysis of the site, it appears to have previously been compromised and threat actors added subdomains which pointed to a Teams phishing pages or YouTube videos. In this case, CYJAX assesses with medium confidence that the go. subdomain was compromised to contain a script which forced visitors directly onto a phishing page hosted on GitHub.

The malicious GitHub page hosted a CAPTCHA impersonating Adobe. This was used to identify bots or sandboxed systems which may be used for analysis. Once completed, this loaded the final github.io page which contained a decoy PDF document and fake download link for Adobe. An example page can be seen below in Figure 4.

Once the “Download Adobe” button was clicked, an iframe popup appears. This was masqueraded as a legitimate Adobe download page in a new tab, as shown in Figure 5.

This is an example of a Browser-in-the-Browser attack, a technique which allows a threat actor to open a pop-up window which acts as a new browser for the phish to continue on. This technique is effective because is a threat actor can show the legitimate URL in the fake browser, rendering many traditional phishing prevention methodologies defunct. In this case, the iframe linked to another github.io page which was controlled by the attacker, containing the code for the fake download page.

From here, a MSI executable posed as the Adobe PDF reader installer was downloaded from Dropbox. This was a Trojanised ScreenConnect installer, a legitimate remote access software. The user was then prompted to run the Adobe PDF reader, which instead ran ScreenConnect hidden in the background and connected to a relay IP address in Canada. It waited for the threat actor to connect to the system.

The webpage also sent an alert to a Telegram bot which indicated that a visitor had downloaded the malware, alerting the threat actor to a potential new victim. The sample alert, shown below in Figure 6, contained location, system, and time zone information which could be used to fingerprint the victim. This is likely used to indicate to the threat actor that a victim had fallen for the phish, and that a ScreenConnect session was likely to be established shortly.

Additional malicious activity was observed after the MSI was deployed. The malware queried and modified the registry, as well as manipulating the legitimate Windows utilities SrTasks.exe and conhost.exe to establish persistence.

Anti-analysis measures

Analysis of the GitHub repository containing the malicious pages uncovered six JavaScript files, shown below in Figure 7. Each of these contain anti-analysis and bot detection capabilities to decrease the likelihood of malicious behaviour detection. This includes custom code for the CAPTCHA, redirections, and fingerprinting.

Whilst all JavaScript files are loaded at runtime, utils.js contains the majority of the anti-detection measures. There are a significant number of capabilities implemented in the script, including the following:

• A denylist to prevent known malicious or researcher-related IP addresses from connecting.
• Tracks user interaction to detect legitimate users against bots, including:
  • Natural mouse movements.
  • Keyboard input.
  • Time spent on page.
  • CAPTCHA fails.
• Checks for privacy features often used by privacy browsers.
• Attempts to fingerprint users based on screen size.
• Detects visitors’ external and internal IP address.
• Detects headless browsers and automation tools.
• Checks for emulation and debugger environments.
• Creates convincing site under construction pages when a bot is detected.
• If one is detected, the site creates infinite loops to overload the CPU of the bot.
• Logs successful human visits.

To prevent the source of the MSI file being exposed, the installer was hosted on Dropbox. Additionally, the phishing page contains an obfuscated downloaded link, shown in Figure 8.

This was encoded in base64 and used the download parameter “dl=1”, which sets the download to hidden mode. As such, users are not alerted to the fact that the download has come from Dropbox. It also used an rlkey, a token which is utilised to bypass the need to login and request access for access to the file. As the link is not hardcoded in cleartext, it provides an extra layer of protection and makes it harder to identify the sources. By using hidden mode download and a rlkey, no user information is tied to the download. This makes it more difficult to identify the Dropbox account used by the threat actor. CYJAX was able to identify that the file was uploaded to Dropbox on 14 October, with information shown below in Figure 9

CYJAX also identified detection evasion methods within the main index.html file. The Adobe icon used in the page was sourced from another website, whilst all other images were base64 encoded and loaded within the webpage’s code.

The site also contained measures to prevent users from using keyboard shortcuts, opening developer tools and the console, and obscured content if analysis-related content is active.

Campaign Analysis

Motivation

ScreenConnect is a commercial remote desktop access software commonly used by threat actors to gain a persistent connection to compromised machines. This could allow further malware deployment, compromise, and exfiltration of sensitive data. As such, the motivations of the threat actor are unclear due to the wide range of potential victims and activity. However, the threat actor does appear to be attempting to access to sensitive data, which may indicate a financial motivation. This is because the data could be exfiltrated for extortion or sold on cybercriminal forums. It is also possible that the attacker aimed to compromise devices for reconnaissance, monitoring victim activity to conduct further attacks.

These phishing pages contain sophisticated anti-analysis and anti-detection measures, increasing the likelihood of successful infection by reducing the chance of malicious detections. By abusing a legitimate service such as Pardot, the threat actor may be able to bypass phishing detection rules, such as those used within emails. Whilst CYJAX could not confirm how victims were exposed to links, the use of a specific PDF document suggests they could be part of a spear-phishing email campaign.

Set-up simplicity

The threat actor appears to have used a template to create these pages, with less than 30 seconds between the initial repository creation and publication of files for the final page. Additionally, the observed GitHub pages hosting Adobe CAPTCHAs appear to be identical. This indicates that the threat actor can easily reproduce pages with no cost and load the malicious iframe by referencing the decoy page.

Additionally, the large number of comments across the repositories code provide us an insight into how the phish is set up. The most notable are comments which indicate what specific elements of the website’s code are for. An example of this is shown below in Figure 10.

Through CYJAX’s analysis of previous Git commits to these malicious repositories, these phishing kits can efficiently be modified to deliver new payloads for services other than Adobe. Figure 12 shows how a different phishing page was loaded using Excel themed content. This is likely a reference to the GitHub repository name xlsxpreview, indicating that this repository has been repurposed to abuse Adobe branding. This highlights that this campaign does not appear to be specifically targeting Adobe users and instead targeted popular business software.

Conclusions

This attack chain portrays the simplification of conducting sophisticated attack campaigns, using GitHub as infrastructure to host free malicious pages. Due to the templated layout of the code, pages are easily replicated and are likely used to replace exposed malicious infrastructure, keeping the attack chain active to create resilience.

This campaign contains many anti-detection measures to prevent traditional reactive threat response and hindering the detection of an ongoing attack. As a result, the most robust mitigation method for this attack chain is to train employees to identify social engineering attempts. This includes knowledge of phishing techniques such as decoy documents, Browser-in-the-Browser, and identifying suspicious file downloads.

Additional protection mechanisms may include monitoring for unexpected traffic, particularly to remote access, IP detection, and file hosting services. The principle of least privilege may aid in mitigation as restricting user access to elevated privileges reduces the impact of compromise. As such, this may prevent users from installing illicit programs.

Mitre ATT&CK

‍

Indicators of Compromise

‍

‍