Executive Summary
GitHub email notifications are being abused to deliver vishing content, according to findings from the Fortra Intelligence and Research Experts (FIRE) team. Vishing, or voice phishing, is a type of social engineering attack in which threat actors attempt to trick their victim into revealing personal information over a phone call or voice message, often beginning with an initial lure sent over email. In fact, vishing content represented around 20% of malicious emails submitted to us for analysis in 2025.
Individuals are targeted with messages containing fake invoices, charges, or billing updates from recognizable brand names, urging the victim to contact a fake support phone number. The immediate impact may be theft of personal information or financial loss for an individual. However, threat actors could trick their victim into installing software on a personal or corporate computer and just as easily compromise corporate credentials or gain access to sensitive business-related data.
Legitimate service abuse and sophisticated email routing methods complicate the detection of phishing content. Companies need to implement layered approaches to detect and defend against these threats, including a clear path for anyone to report phishing attempts, and most importantly, employee training.
Introduction
While abuse of GitHub’s legitimate email notification system has been observed before, this is the first time Fortra has seen it used for vishing attacks by including the malicious content in the commit messages of otherwise empty GitHub profiles and repositories.
GitHub is a web-based platform primarily used for version control and collaborative software development. A commit is a snapshot of changes made to the code in a repository. These include a section where developers usually describe the changes they have made. Threat actors are now placing lures within this comment section encouraging victims to call a fraudulent customer care number.
Another key aspect of this campaign is how these email lures are forwarded through Microsoft 365 services. Threat actors first register Google or Fastmail email addresses for notifications from GitHub, where they then receive the original notification. Those email notifications are then routed to Microsoft 365, where they are forwarded to the final recipient(s). Routing through Microsoft is a tactic employed to bypass email filters by ensuring the source is trusted and authentication checks do not fail.
How It Works
The final recipient's email address is completely absent from the headers of the submitted samples, prompting us to investigate further. We analyzed approximately 67 samples received in the span of a week and found that they all shared key characteristics.
The body of these messages mimics invoice receipts and billing updates, notifying of a purchase or subscription renewal to recognized brand names such as PayPal, Norton, Geek Squad, and McAfee.
These types of messages often include the overuse of emoji symbols or special characters, giving an odd formatting to some letters or perhaps entire words. How much the victims perceive those formatting differences will depend on the email client where these are viewed. Threat actors also employ this technique to evade detection mechanisms based on keyword pattern recognition.
Basic header information:
The ‘From’ field is always [email protected].
The ‘To’ field could be @onmicrosoft.com, @gmail.com, @emailengine.net or an [email protected] address.
The Return-path is always an [email protected] address.
Note: The initial recipient could be a [email protected] email address. This is because GitHub provides a default noreply address to every user. It is intended to keep the user’s real email address private.
The term "bounces+SRS=" refers to the Sender Rewriting Scheme (SRS) used by Microsoft 365 to handle email forwarding to external recipients. It modifies the ‘MAIL FROM’ value to prevent SPF (Sender Policy Framework) failures when forwarding. The Return-Path is re-written to onmicrosoft.com. This is the default domain for new Microsoft 365 tenants. However, SRS does not alter the ‘HEADER FROM’ value, meaning the ‘From’ address displayed in the recipient's email client remains unchanged.
Legitimate notifications coming from GitHub will include a Return-path to the same domain. We confirmed this by comparing them to a normal email notification with no forwarding set up.
In the example shown above, the ‘To’ field is populated by a free email address with a Fastmail domain. This threat-actor-controlled account receives the GitHub notification first. It is then either manually or via a forwarding rule sent to an onmicrosoft.com address.
Not all samples analyzed use a free email as a first step. Many were configured to send notifications directly to a default Microsoft 365 tenant email address.
Threat actors can configure this process in such a way that the final recipients' email addresses remain hidden. As a result, the number of addresses is obscured during the forwarding process, complicating our efforts to determine the true scale of the campaign. Since the vishing content is not personalized, threat actors can target multiple recipients with the same message.
The first ‘Received: from’ shows us the real github.com domain and authentication checks pass. X-GitHub-Recipient-Address is also present in the headers. This is added by GitHub’s email notification system, likely pointing towards service abuse as opposed to spoofing of the github.com domain.
GitHub Abuse
We can confirm our suspicion of service abuse by trying to understand how the emails originated. The email notifications contain URLs with valuable information pointing us to the source.
Example:
Breakdown:
“Order976” is the GitHub username or profile.
“ssssss” is the name of specific repository that lives under that profile.
“commit/cac4e1ac0581e081f38486caaa0468775f9869ab” is a unique identifier for the commit.
Most profiles were quickly removed no more than two days after generating these emails. This could be because of GitHub takedown actions or the threat actors closing the accounts themselves.
There were, however, some active users. The example provided below is notable as it is impersonating Norton, a popular antivirus solution and an often-abused name in vishing attacks. That being said, there are no publicly available repositories or a history of contributions for this account. Threat actors can set repositories and contribution activity to private, which means it is only viewable by the account owner.
Out of the five profiles we discovered at least one had repositories that were publicly accessible, allowing us to gain insight into how they are used. It seems the threat actors had been careful to configure the privacy settings up to this point.
The repositories analyzed don’t contain any code, and there aren’t any changes to a real code project. These are mostly empty repositories except for the README.md, which is commonly the first file added when a new repository is created, or a .github/workflows directory which is generally intended for setting up automation workflows.
Within the workflows directory files are added with deceptive names such as “Payment confirmation 00653” or “Receipt received”. These files don’t contain any valuable information themselves. Instead, the lure can be viewed within the commit details. What the threat actors are doing is including the lure in the description box of that change being submitted, in this case when adding these files.
The deceptive filename will be displayed in the subject line of the email notification, while the commit details will be presented as a significant part of the email body. Deceptive usernames are employed, such as Order976 and Norton143. These names will be the only thing some users view as a sender, depending on the email client they are using.
Looking into the contribution activity for the same profile paints the picture that this is likely to be a large campaign. This account alone had 44 repositories and already made 133 commits at the time of writing, each sending messages to an undetermined number of inboxes. Although GitHub typically only allows for a limited number of email addresses to receive updates, as mentioned before, these are being forwarded through Microsoft 365, which allows the final recipient count to be obscured.
Takeaways
Threat actors reuse tactics; they combine them with newer exploits and continue to develop their methods for delivering phishing content. Understanding their tactics enables us to determine where we should look and what we need to look for when defending against these attacks.
Implementing robust detection mechanisms for email content is crucial. Relying on sender email addresses alone or basic pattern recognition is not enough when we see constant abuse of trusted services to deliver specially crafted messages intended to deceive. SPF, DKIM, and DMARC are important, but threat actors can circumvent or leverage them in their favor. The detection mechanisms we set up should utilize the content in the body and take other aspects into consideration, such as routing and special characters that seem out of place.
Employees also need access to a reliable way for reporting phishing attempts to their security teams, as messages like this will likely continue to reach inboxes. The underlying threat remains the deceptive messaging designed to play on people’s fears or willingness to help. Social engineering attacks are effective for these reasons, and the best tool at our disposal remains employee awareness and training.
Artifacts
Vishing Phone Numbers
+1 805 507 3546
+1 805 500 6927
+1 804 575 2892
+1 805 500 6071
+1 828 398 4040
+1 970 303 2136
+1 806 577 1378
+1 802 310 7038
GitHub Users
billrp
Customer-Billing
Invoice-Info
NORTON143
Order976
Receipt-Team
SDDSSFAFA
Interested in Securing Your GitHub Data?
Learn about other prominent GitHub security risks in our recent blog.
