• Cisco Talos has recently started to collect and gather intelligence around phone numbers within emails as an additional indicator of compromise (IOC). In this blog, we discuss new insights into in-the-wild phone number reuse in scam emails.  
• According to Talos’ observations, the ease of API-driven provisioning makes a few VoIP providers the preferred tool for attackers, allowing for high-volume, cost-effective scam operations that are difficult to trace. 
• Attackers maintain operational continuity by rotating through sequential blocks of phone numbers and utilizing strategic cool-down periods, with a median phone number lifespan of 14 days, to effectively evade reputation-based security filters. 
• Threat actors try to maximize their reach by recycling the same phone numbers across diverse, seemingly unrelated lures - including varied subject lines and different attachment formats like HEIC and PDF - to impersonate multiple brands simultaneously. 
• Security researchers can expose the hidden infrastructure of organized scam call centers by shifting focus from ephemeral email addresses to phone numbers, using clustering techniques to connect disparate campaigns and strengthen overall defensive postures.

Telephone-oriented attack delivery (TOAD) continues to be a prevalent tactic in modern email threats. By shifting the communication channel from email to a real-time conversation, attackers manipulate victims into disclosing sensitive information or installing malicious software. 

Cisco Talos has expanded its threat intelligence capabilities to include phone numbers as a critical IOC. Our analysis covers a wide spectrum of line types, including wireless (cellular), landline, and Voice over Internet Protocol (VoIP). While scammers leverage all three, VoIP numbers are particularly prevalent due to their ease of acquisition and the difficulty of tracing them back to their origin. In fact, six of the ten largest campaigns we detected between February 26 and March 31, 2026 relied on VoIP infrastructure.

To better understand how these numbers are weaponized, this blog first explains the technical structure of VoIP numbers and the role of service providers in this ecosystem. We then broaden the scope to analyze reuse patterns, lifespan, and campaign characteristics across all line types. By sharing these insights, Talos aims to strengthen our collective defensive posture against these evolving threats.

The structure of VoIP phone numbers 

Most VoIP numbers follow the E.164 international public telecommunication numbering plan. This format ensures that every number is globally unique and can be routed correctly across the Public Switched Telephone Network (PSTN). 

An E.164 number is limited to 15 digits and consists of: 

1. International Prefix (+): Indicates the number is in international format 
2. Country Code (CC): 1 to 3 digits (e.g., 1 for the US/Canada, 44 for the UK) 
3. Area Code/National Destination Code (NDC): Often referred to as the area code 
4. Subscriber Number (SN): The specific number assigned to the user or device 

The above components are shown in the example phone number below:

The VoIP ecosystem 

Voice over Internet Protocol (VoIP) has become the primary medium for scam campaigns due to its cost effectiveness, ease of deployment, and API-driven automation. Within this ecosystem, we identify two primary operational models: wholesalers and retailers. VoIP wholesalers (e.g., Virtue, Twilio, and Bandwidth) operate in a business-to-business (B2B) capacity, sitting between Tier 1 carriers (e.g., AT&T, Verizon) and smaller service providers, selling high volumes of numbers in bulk. Conversely, VoIP retailers (e.g., RingCentral) sell finished business calling and collaboration solutions directly to organizations and end users. 

VoIP providers are further categorized into communications platform as a service (CPaaS) and unified communications as a service (UCaaS). CPaaS providers offer programmable APIs that allow developers to integrate voice and messaging directly into applications. Because these platforms are designed for automation and high-volume traffic, they are frequently exploited by threat actors for rapid, API-driven number provisioning. In contrast, UCaaS providers offer comprehensive, end-user-facing communication suites. UCaaS platforms are typically designed for legitimate enterprise collaboration, and that makes them less attractive for scam email campaigns. Talos has found Sinch (primarily a leader in CPaaS) as the most commonly abused VoIP provider, and Verizon and NUSO as the least abused providers in the studied time window.

While VoIP line types dominate the scam landscape (see Figure 2), Talos has observed that threat actors utilize wireless (cellular) and landline numbers as well. Cellular numbers are harder to provision at scale, as they typically require physical SIM cards and stricter customer verification, making them more expensive and less disposable than VoIP numbers. Nevertheless, they are still widely adopted by scammers. Figure 3 shows the distribution of wireless carriers that are used byscammers in the studied time window. Landline numbers, on the other hand, are used to project a sense of local presence or established business legitimacy. By using a landline with a specific local area code, scammers can effectively impersonate local businesses (e.g., banks, utility companies, or government offices).

Phone number reuse and lifespan in scam campaigns 

In this section, we provide insights into the lifecycle of phone numbers used in scam emails, examining how often they are reused, their typical lifespan, and how they appear across seemingly unrelated lures. Our analysis focuses on scam campaigns impersonating popular brands, including PayPal, Geek Squad (Best Buy), McAfee, and Norton LifeLock. 

Phone number reuse patterns 

Talos identified 1,652 unique phone numbers across these campaigns during the studied time window (February 26 to March 31). Of these, 57 numbers (approximately 3.4%) were reused across multiple consecutive days. The longest period of reuse observed for a single phone number was four consecutive days. 

As discussed in a previous blog post, phone numbers are reused for several strategic reasons. First, intelligence regarding phone numbers is often distributed more slowly than that of URLs or file hashes; many numbers remain under the radar of third-party reputation services for several days. Second, reuse offers logistical advantages for scam call centers, allowing them to maintain a consistent brand presence for multi-stage social engineering, callback scheduling, and persistent victim engagement. Finally, reuse minimizes operational costs, particularly for paid VoIP services. While we observed some phone numbers reused for up to four consecutive days, the most common reuse period was two consecutive days.

Lifespan analysis and cool-down periods 

Scammers do not always reuse phone numbers on consecutive days. Often, they implement a cool-down period — pausing the use of a number for a few days to evade detection — before reintroducing it into a campaign. 

Our investigation into the lifespan of these numbers revealed that 108 phone numbers (~6.5%) remained active for more than one day. As shown in Figure 4, most phone numbers have a lifespan of two to six days, though a handful remained active for nearly a month. During the study window, the median lifespan was approximately 14 days. Notably, infrastructure longevity often correlates with the impersonated brand; as illustrated in Figure 5, PayPal-themed scam campaigns utilized significantly more persistent phone numbers than those impersonating Norton LifeLock.

Phone numbers across unrelated lures 

A scam or phishing lure is typically a combination of a business context, a psychological trigger, a call-to-action, and an impersonated brand (see Table 1 for a few examples). These lures appear across various email layers, including subject lines, body content, and attachments.

Table 1. Examples of lures that most commonly appear in scam or phishing emails.

We observed phone numbers being recycled across diverse, seemingly unrelated lures: 

• Using the same phone number across multiple lures in the subject line: In one campaign, a single phone number appeared across multiple business contexts, such as "order confirmation" and "financial transaction verification." Figure 6 demonstrates how these subject lines differ, despite the emails containing the same phone number and impersonating the same brand.

• Using the same phone number across multiple document-based lures: In a second campaign, a single phone number was embedded in PDF attachments used for both “subscription renewal” and “financial transaction verification.”Interestingly, this campaign utilized two different brands — PayPal and Norton LifeLock — to redirect recipients to the same call center, leveraging urgency as a psychological trigger.

• Using the same phone number across multiple attachment file formats: In a third campaign, a single phone number was embedded in two different attachment formats: HEIC and JPEG. The use of HEIC (High Efficiency Image Container) — a format often used for iPhone/iPad photos — demonstrates the attackers' efforts to bypass traditional file-based detection while maintaining high image quality. Talos has observed campaigns utilizing even more attachment types, confirming that threat actors frequently distribute a single phone number across multiple attack vectors to maximize their reach.

Phone block-level clustering 

In the context of scam emails and related smishing or callback scams, attackers utilize specific VoIP grouping and clustering techniques to bypass security filters, appear legitimate, and maintain high-volume operations. One of the most common tactics is sequential number grouping. Scammers often obtain large ranges of sequential phone numbers by purchasing Direct Inward Dialing (DID) blocks. Consequently, if a specific number is flagged as spam and blocked by a carrier, the attackers simply rotate to the next number in the block. 

The figure below shows how a block of numbers — differing only in the last four digits — is used in various scam emails impersonating PayPal between March 3 and March 6, 2026. It is also clear that certain numbers are used in larger campaigns than others; for instance, “+1 804[-]713[-]4598” was used in 117 scam emails in a single day.

In large-scale scam campaigns, phone numbers within a single sequential block are reused across multiple brand lures. The figure below shows how a range of numbers in a sequential block is deployed across three different brand lures. As with the previous case, some phone numbers are utilized in significantly larger campaign volumes than others.

Conclusion and protection 

When tracking scam campaigns, it is essential to look beyond individual sender email addresses, which are often ephemeral. Instead, it is more strategic to focus on phone numbers, which serve as the true anchors of the operation. By clustering scam lures based on shared phone numbers, security researchers can effectively map connections between seemingly unrelated campaigns, ultimately exposing the infrastructure of organized criminal call centers. 

Service providers and security teams should prioritize the implementation of real-time reputation monitoring for different communication channels to proactively mitigate these threats. For example, establishing centralized databases that track and flag high-risk phone numbers across multiple platforms allows for rapid cross-campaign correlation. Collaboration between telecommunications and VoIP providers is also vital, as sharing threat intelligence regarding malicious telephony infrastructure enables an industry-wide defense against the persistent threat of social engineering and fraud. 

Cisco Secure Email Threat Defense 

Protecting against these sophisticated and devious threats requires a comprehensive email security solution that harnesses AI-powered detections. Cisco Secure Email Threat Defense utilizes unique deep and machine learning models, including Natural Language Processing, in its advanced threat detection systems that leverage multiple engines. These simultaneously evaluate different portions of an incoming email to uncover known, emerging, and targeted threats.

Secure Email Threat Defense identifies malicious techniques used in attacks targeting your organization, derives unparalleled context for specific business risks, provides searchable threat telemetry, and categorizes threats to understand which parts of your organization are most vulnerable to attack. You can sign up for a free trial of Email Threat Defense today. 

By Diana Brown

• Cisco Talos has recently observed an increase in activity that is leveraging notification pipelines in popular collaboration platforms to deliver spam and phishing emails.
• These emails are transmitted using the legitimate mail delivery infrastructure associated with GitHub and Jira, minimizing the likelihood that they will be blocked in transit to potential victims.
• By taking advantage of the built-in notification functionality available within these platforms, adversaries can more effectively circumvent email security and monitoring solutions and facilitate more effective delivery to potential victims.
• In most cases, these campaigns have been associated with phishing and credential harvesting activity, which is often a precursor to additional attacks once credentials have been compromised and/or initial access has been achieved. 
• During one campaign conducted on Feb. 17, 2026, approximately 2.89% of the emails observed being sent from GitHub were likely associated with this abuse activity. 

Platform abuse, social engineering, and SaaS notification hijacking 

Recent telemetry indicates an increase in threat actors leveraging the automated notification infrastructure of legitimate Software-as-a-Service (SaaS) platforms to facilitate social engineering campaigns. By embedding malicious lures within system-generated commit notifications, attackers bypass traditional reputation-based email security filters. This Platform-as-a-Proxy (PaaP) technique exploits the implicit trust organizations place in traffic originating from verified SaaS providers, effectively weaponizing legitimate infrastructure to bypass standard email authentication protocols. Talos' analysis explores how attackers abuse the notification pipelines of platforms like GitHub and Atlassian to facilitate credential harvesting and social engineering. 

The PaaP model 

The core of this campaign relies on the abuse of SaaS features to generate emails. Because the emails are dispatched from the platform's own infrastructure, they satisfy all standard authentication requirements (SPF, DKIM, and DMARC), effectively neutralizing the primary gatekeepers of modern email security. By decoupling the malicious intent from the technical infrastructure, attackers successfully deliver phishing content with a "seal of approval" that few security gateways are configured to challenge. 

Anatomy of GitHub campaign: Abusing automated notification pipelines 

The GitHub vector is a pure "notification pipeline" abuse mechanism. Attackers create repositories and push commits with payloads embedded in the commit messages. The User Interface Mechanism has two fields for text input: one is a mandatory summary, a single limited line, where the user provides a high-level overview of the change. Attackers weaponize this field to craft the initial social engineering hook, ensuring the malicious lure is the most prominent element of the resulting automated notification. The second field is an optional, extended description that allows for multi-line, detailed explanations. Attackers abuse this to place the primary scam content, such as fake billing details or fraudulent support numbers.  

By pushing a commit, the attacker triggers an automatic email notification. GitHub’s system is configured to notify collaborators of repository activity. Because the content is generated by the platform’s own system, it avoidssecurity flags. In this example, we can see the details of the commit followed by the scam message. At the bottom of the email, we have the mention of the subscription, buried at the very bottom of the page. 

The chain of Received headers shows the message entering the system from “out-28[.]smtp[.]github[.]com” (IP “192[.]30[.]252[.]211”). This is a known legitimate and verified GitHub SMTP server.  

The email contains a DKIM-Signature with “d=github[.]com”. This signature was successfully verified by the receiving server (“esa1[.]hc6633-79[.]iphmx[.]com”), proving that the email was sent by an authorized GitHub system and was not tampered with in transit. Telemetry collected over a five-day observation period indicates that 1.20% of the total traffic originating from “noreply[@]github[.]com” contained the "invoice" lure in the subject line. On the peak day of Feb. 17, 2026, this volume spiked to approximately 2.89% of the daily sample set. 

Abusing workflow and invitation logic (Jira) 

The Jira vector does not rely on a notification pipeline in the traditional sense. Jira notifications are expected in corporate environments. An email from Atlassian is rarely blocked, as it is often critical for internal project management and IT operations. The abuse here is not a "pipeline" of activity, but an abuse of the collaborative invitation feature.  

Attackers do not have access to modify the underlying HTML/CSS templates of Atlassian’s emails. Instead, they abuse the data fields that the platform injects into those templates. When an attacker creates a Jira Service Management project, they are given several fields to configure. When the platform triggers an automated “Customer Invite” or “Service Desk” notification, it automatically wraps the attacker’s input — such as a fraudulent project name or a deceptive welcome message — within its own cryptographically signed, trusted email template. By utilizing a trusted delivery pipeline, the attacker successfully obscures the origin and intent of the malicious. 

In this example, the attacker sets the "Project Name" to "Argenta." When the platform sends an automated invite, the email subject and body dynamically pull the project name. The recipient sees "Argenta" as the sender or the subject, which the platform has verified as the project name. 

The attacker placed their malicious lure subject into the "Welcome Message" or "Project Description" field. They use the "Invite Customers" feature and input the victim's email address. Atlassian’s backend then generates the email. Because the system is designed to be a "Service Desk," the email is formatted to look like a professional, automated system alert. At the bottom of the phishing email, we can see the branding footer that Jira automatically appends to email notifications.  

Strategic implications 

The trust paradox is now the primary driver of successful phishing and scamming. GitHub is abused primarily for its high developer reputation, where attackers rely on the platform’s status as an official source of automated alerts. In contrast, Jira is abused for its business-critical integration; because it is a trusted enterprise tool, attackers use it to mimic internal IT and helpdesk alerts, which employees are pre-conditioned to treat as urgent and legitimate. In both cases, attackers are using the platform's own reputation to launder their malicious content. 

How do we fundamentally change the trust model? 

Defending against PaaP attacks requires moving from the binary “trusted vs. untrusted” approach. Because attackers weaponize the platform’s own infrastructure to bypass authentication protocols (SPF/DKIM/DMARC), the gateway is effectively blind to the malicious intent. Defenders should transition to a Zero-Trust architecture that treats SaaS notifications as untrusted traffic until verified against platform-level telemetry. Moving beyond the limitations of the email gateway and adopt a fundamental paradigm shift: transitioning from reactive, signature-based filtering toward a proactive, API-driven model architecture that validates intent before a notification ever reaches the user.  

Identity and instance-level verification: We must move from "global domain trust" to "instance-level authorization." Security teams should restrict notification acceptance to specific sender addresses or IP ranges associated with their organization’s verified SaaS instances. Furthermore, by implementing Identity-Contextualization, notifications must be cross-referenced against the organization's internal SaaS directory. If a notification originates from an external or unverified account — even one hosted on a trusted platform like GitHub — it should be automatically quarantined. Verification is no longer about the server sending the email; it is about the identity of the user triggering the action. 

Upstream API-level monitoring: The most effective way to disrupt PaaP campaigns is to detect them before the notification is ever sent. Attackers must perform "precursor activities" within the platform — such as creating repositories, configuring project names, or mass-inviting users — to set the stage for their cyber-attack. By ingesting metadata from SaaS APIs (e.g., GitHub or Atlassian audit logs) into a SIEM/SOAR environment, security teams can identify these anomalous events in real-time. Detecting a "Project Creation" event that deviates from established naming conventions, originating from a country where the receiving organization has no employees or occurs outside of business hours allows for the preemptive suspension of the malicious account, neutralizing the threat at the source. Instead of waiting for a phishing email to arrive in an inbox, defenders are watching the attacker’s movements inside the platform as they set up the attack. 

Semantic intent and behavioral profiling: We must replace simple keyword matching with Business Logic Profiling. Every sanctioned SaaS tool has a functional "Communication Baseline." GitHub is for code collaboration; Jira is for project management. By defining these baselines, security teams can detect "semantic discontinuity," when the content of a notification (e.g., urgent financial billing) is incongruent with the platform's primary utility. Any notification that deviates from the expected functional profile should trigger an automated "Suspicious" banner or be routed for manual review, regardless of its technical validity. 

Mitigating cognitive automation fatigue: PaaP attacks exploit "automation fatigue," where users are conditioned to trust system-generated alerts. To break this cycle, organizations can introduce intentional friction. For high-risk SaaS interactions, such as new project invitations or requests for sensitive data, security policies should mandate out-of-band verification. By requiring a platform-native verification code or forcing the user to navigate directly to the official portal rather than clicking a link, we remove the "reflexive trust" that attackers rely on. This ensures that the platform’s "seal of approval" is validated by a deliberate human action. 

Automated takedown orchestration: Finally, the cost of attack must be increased. Security teams should integrate automated workflows that report malicious repositories or projects directly to the provider’s Trust andSafety teams. By accelerating the detection-to-takedown lifecycle, we force adversaries to constantly churn their infrastructure, making the PaaP model technically and economically unsustainable. 

By adopting this framework, the security posture evolves from "Is this email authenticated?" to "Is this platform activity authorized and consistent with our business logic?" This shift effectively strips the trusted status that attackers exploit, forcing them to operate within an environment where their actions are monitored, profiled, and verified at every stage of the pipeline. 

Acknowledgements 

Special thanks to the Talos Email Security Research Team — Dev Shah, Lucimara Borges, Bruno Antonino, Eden Avivi, Marina Barsegyan, Barbara Turino Jones, Doaa Osman, Yosuke Okazaki, and Said Toure — for their collaborative effort in identifying and mitigating these platform abuse vectors. 

Indicators of compromise (IOCs) 

IOCs for this threat can be found on our GitHub repository here.