Imposter Repos: Phishing Software Engineers on GitHub

Netragard was approached by a software development firm to emulate a threat actor attempting to gain access to their Intellectual Property (IP) through social engineering. The client specifically requested a black-box approach, targeting the company’s software engineers.

A black-box approach involves starting the engagement without any prior information, simulating a threat actor operating with real-world resources. In this article, we delve into how we crafted a convincing social engineering campaign, hosted Command and Control (C2) implants on GitHub, and eventually gained remote access to a software engineer’s corporate laptop.

Anonymity and Quality

It’s important to note, we believe in protecting our clients’ identities and letting the quality of our work speak for itself.  To that end, we’ve altered certain aspects of this story to ensure our client remains anonymous.

Part 1: The Reconnaissance

Starting with only the company’s domain name, we began our initial phase of information gathering. This process typically involves extensive enumeration including examining historical and active DNS records, using Google dorking to find publicly accessible files, uncovering cloud hosting services, identifying vendor products in use, and documenting employee information.

Although open-source intelligence gathering is just the first step, it is often the most crucial phase of the entire engagement. Overlooking even a single piece of information during this process can lead to missed opportunities for later leverage. By accumulating comprehensive data, we can construct a holistic view of a company’s online presence, which is essential for effective operational planning.

Public DNS & Banyan

Using various methods, we gathered approximately 1,500 DNS records associated with the client. The names of these records hinted at vendors the company had either previously used or was still actively using, such as Banyan, a zero-trust security solution that can be integrated into a company’s Single Sign-On (SSO) platform. We discovered many subdomains hosting web services which were redirecting to the Banyan login portal, hinting at extensive use across the company. Encountering this product repeatedly indicated that many employees were likely familiar with the Banyan application, an observation that we would later use in our spear phishing campaign.

Additionally, over 500 of these DNS records resolved to internal IP addresses, providing us with insights into the networks hosting the client’s staging and production servers, authentication portals, git platforms, and more. This information grants a significant advantage to us (or potential attackers) once we gain access to the internal network. It allows precise targeting of internal assets before establishing a foothold on the company’s internally-connected systems.

LinkedIn & Gmail Validation

We then headed towards the de-facto treasure trove of quasi-public employee information: LinkedIn. Using a mixture of open-source and in-house tools, we automatically scraped company LinkedIn pages and saved the information to a spreadsheet for future parsing.

Not only did we acquire the employees’ names and titles, but we also obtained their respective employment start dates. This information enabled us to organize our targets by their tenure, starting with newer, low-risk employees and gradually moving towards senior staff who are likely to be more skeptical of a given social engineering scenario.

Once we obtained employee’s first and last names, we were able to methodically enumerate the company’s email format and validate each user’s email address. By reviewing the company MX records, we confirmed that the company uses Google for email services. Therefore, we chose to validate the email addresses using SMTP’s RCPT TO method for enumeration against Google’s servers. We first automated the process of identifying the correct format for a single user, then verified all remaining email addresses using the identified format.

Selecting the Attack Vector

It was time to decide on our exact manner of attack. We considered several phishing scenarios, including a CircleCI social engineering campaign after noticing a publicly available instance with failed build jobs. However, further assessment of our client’s footprint revealed a publicly accessible GitHub organization. After some brainstorming and discussion, we decided to proceed with leveraging GitHub for our campaign.

---

An organization in GitHub is a feature used to group people and projects for collaboration purposes. An organization’s administrator can invite anyone’s GitHub account, by username or by email address, to the organization where members can be granted access to associated coding projects known as repositories.

---

The high-level plan involved creating a duplicate of the company’s GitHub organization with a slight name variation. Next, we’d establish a new private repository containing our Command and Control (C2) implant payloads. The final step was to invite unsuspecting employees to this repository, enticing them to execute the hosted payload files. Leveraging the trusted Microsoft GitHub platform for email invites would likely bypass configured filters, ensuring successful delivery to each employee’s inbox. Additionally, hosting the payload files on a trusted domain would reduce scrutiny during downloads. Lastly, by posing as a private internal company repository, we minimized the likelihood of drawing employee suspicion when introducing a call-to-action.

Part 2: Assembling the Pieces

We started with creating several GitHub accounts that looked identical to those associated with our client’s public GitHub organization. We changed the usernames slightly and copied the avatar profile pictures. Using one of these impostor accounts, we then created a new Github organization with a permutation of the original legitimate name. To create a sense of familiarity, we cloned all publicly available repositories within their organization and re-uploaded them into our organization. We copied the logo, some metadata, made our impostor organization user profiles public, and configured identical social media links. Though we can’t share our comparison screenshots, we assure you that the recreation was nearly indistinguishable from the original GitHub organization.

C2 & Malware Staging

Inside our impostor organization, we then created a new private repository with an enticing README file. This repository claimed to be the new company software license key management solution and stated that its installation would soon be mandated company-wide. It also included several helpful screenshots which complemented the installation instructions, as well as an activation key which was meant to be copied by users.

This malicious key manager application was conveniently created for both Windows and MacOS, allowing software engineers using either platform to download our executable from GitHub via the repository releases feature.

This executable, commonly referred to as a dropper, had our malicious C2 implant, a fake Banyan application based on the recon in part 1, encrypted and embedded within. The use of a dropper helps prevent the C2 implant from being detected should the file be subjected to static analysis, and instead the dropper must be executed in order for the C2 payload to be revealed.

---

A dropper is a type of malware payload designed to extract and save, execute, and/or install other malicious software payloads onto a target system. It typically evades detection by using various techniques to deliver and execute the final payload discreetly.

---

To help avoid raising suspicion, we meticulously crafted the MacOS dropper to simulate a typical MacOS application installation experience. The application was packaged into a MacOS app bundle and then copied into a disk image (DMG) file, allowing us to replicate the signature MacOS drag-and-drop installation process that Apple users are familiar with. Upon mounting the DMG file, the End User License Agreement (EULA) appeared on the screen featuring the usual jargon as well as some hidden easter eggs at the bottom for those who read it diligently.

At this point, the target users are able to see a typical software installation UI requiring them to only drag the application icon over the MacOS Applications icon in order to copy the key manager dropper files and complete the installation. Once completed, the dropper can be launched like any other installed software from the MacOS Applications directory.

Once executed, an input prompt was presented to the user, requiring them to enter the activation key from the GitHub repo README file before the dropper would decrypt and execute the C2 implant. This ensured that only intended target users would be able to execute the C2 implant, but it also helps shield the C2 implant from any dynamic sandbox analysis, such as VirusTotal or proprietary “cloud scanning” engines used by many EDR vendors. This anti-sandbox technique falls under the broader category of payload guardrails. Other guardrails implemented within this and other payloads Netragard commonly uses include expiration dates to ensure payloads abort (or self-delete) once the project ends, environmental keying to ensure payloads will only execute on intended client systems, and mutex mechanisms to ensure that a payload will only execute once on a given system.

Testing the C2 Implant

With the company seemingly utilized Banyan across many network assets, this branding (via not only filename but also icon and other metadata) seemed like a good choice for a C2 implant dropped to disk. For both MacOS and Windows, our custom dropper’s C2 implants for this engagement were obfuscated and compiled using a variety of both platform-agnostic and OS-specific evasion strategies, tested rigorously, and leveraged proprietary techniques to circumvent popular EDR platforms.

When a user runs the Key Manager application downloaded from the Imposter Github Organization, upon successful execution and “activation”, a file named either banyanwatcherdog.exe (Windows) or  com.banyan.watchdog (MacOS) would be decrypted, extracted to the local disk, and automatically launched. The C2 traffic then connects back to our attacker controlled, legitimate, Microsoft Azure hosting service at https://banyan-ztna.azurewebsites.net. This Azure service acts as an intermediary, forwarding HTTPS traffic to the legitimate C2 server while ensuring proper filtering and forwarding of C2 requests. This helps maintain stealth and evade detection.

Launching the Attack

With all the pieces finally in place, we began sending out invites to the repository. Each email invite was sent from GitHub on behalf of our impostor organization and its associated administrator account. Slowly a few people began accepting the invites, and it became a waiting game to see if anyone would take the bait of the call-to-action outlined in the repo README file.

After some time had passed, we finally received an HTTPS connection from our C2 implant which came from a MacOS device. The associated username on the MacOS system which executed the payload was, in fact, the company’s newest software engineer that we had found on LinkedIn. Three cheers for a recon-driven strategy and scenario coming to fruition!

Although our hard work had seemingly paid off, the C2 connection was short-lived. We lost connection to the machine before we could establish persistence or exfiltrate any objective data.  After losing connection, we concluded our engagement with a volley of high-risk, high-reward email invites. We sent all remaining invites to senior employees and some security team members, hoping someone would execute the files. We also continuously monitored our payload hashes on VirusTotal (VT), and we eventually observed that a security analyst for the company had uploaded our dropper files. The VT results were in, and we had scored a 1/71 detection rating.

Despite this, we successfully demonstrated how a threat actor could perform reconnaissance sufficient to craft a social engineering scenario sophisticated enough to compromise even the technically savvy employees, ultimately obtaining access to corporate systems operated by privileged users in a manner which evades the latest security products and technologies.

Additional Insights

While sending out our private GitHub repository invites to each email address, we noticed something remarkably interesting. Under the hood, GitHub’s API would automatically reveal the usernames associated with the provided email address, even if the GitHub user does not accept the invite. To top it off, a standard GitHub account can make 50 invite requests every 24 hours. This functionality is ripe for abuse, as it allows a threat actor to spray invites to a list of company email addresses to reveal associated GitHub account usernames. Using a little automation, we can submit up to 50 user emails and collect a list of associated GitHub accounts.

This would allow us to target employees from a different attack vector. If a GitHub account has its own public repositories, it is very likely that personal emails are associated with some of the git commits within the repo. An attacker could then leverage the personal email addresses revealed via this technique by checking them against public breach data. Any compromised credentials could, then in turn, be used to attempt authentication against company assets, opening another potential pathway for infiltration in the event of credential re-use. To make this even easier, we were able to write up a quick script to crawl each GitHub profile, download all associated repositories that weren’t forked from elsewhere, and then run a series of tools against each repository to identify data of interest.

Additionally, each repository may inadvertently contain secrets embedded within the code or other included configuration files. Unfortunately, this is quite common, with nearly 13 million secrets discovered in public GitHub repositories in 2023 alone. These secrets include Google API keys, passwords, secure tokens, and more. There’s always a risk that a developer could accidentally leak personal or company credentials or other sensitive information within their GitHub repo’s code. This is a powerful reminder that strong company policies, good digital hygiene practices, and other proactive technical measures can go a long way to prevent these types of attacks.

Key Takeaways

This phishing technique highlights the critical need for ongoing cybersecurity education and awareness. As attackers become more innovative, they exploit trusted platforms and mechanisms to execute sophisticated phishing campaigns. By understanding the methodologies employed in these attacks, you can better protect your organization against the ever-evolving threat landscape. Here are the key takeaways from this case study to improve the security posture at your organization:

• Avoid setting public DNS records to internal IP addresses. Instead use an Internal or Private DNS Zone if the resource doesn’t need to be externally accessible to the organization.
• Implement Application Whitelisting to restrict the usage of any tools or applications to those that are already vetted and approved by IT.
  • Windows Defender Application Control or AppLocker for Windows
  • Gatekeeper for MacOS
• Monitor network traffic to identify and block unusual traffic patterns and new/uncommon IP connections.
• Ensure users create new Github accounts that are dedicated to the organization, instead of using personal Github accounts for organization invites.
• Enable Domain Verification for your Github Organization. After verifying ownership of your organization’s domains, a “Verified” badge will display on the organization’s profile.
• Build awareness for phishing and consider targeted awareness campaigns for developers and technical staff that cover trusted, online, development platforms like Github, CircleCi, etc..
  • Scrutinize unsolicited emails
  • Confirm call-to-actions before completing
  • Don’t inherently trust known platforms
  • Don’t download/open/run files without IT approval