• As frontier models advance in cyber capability, their guardrails also become more restrictive. 
• Defenders relying on these models to power core SOC processes cannot afford to pay the “safety penalty” of being blocked by these safeguards. 
• Organizations should monitor model refusal rates and use the data to create a strategy to ensure operational sovereignty.

The allure of the cloud and the hidden "safety penalty" 

Cybersecurity has made a big bet on cloud-hosted AI. Building and running frontier-class models in-house isn’t realistic for most security teams — the compute, the talent, and the R&D costs are more than any single SOC can carry. So we’ve effectively outsourced the "brain" of our security operations to a handful of providers. 

That trade comes with a hidden cost: the safety penalty. 

The safety penalty is the friction that shows up when guardrails built to protect the general public get in the way of legitimate security work. If your model refuses to deobfuscate that malware or to explain a working exploit because its filters read the request as harmful, you’re paying the safety penalty. 

Those guardrails make sense in a normal business context and may even be a welcome feature when it comes to keeping agents in check. But in a SOC, in the hands of defenders aiming to reap the full benefits of powerful AI models, these guardrails are a bug. Every refusal sends the analyst back to doing the work by hand, and in a live incident, that lost time is a luxury we don’t have. 

Meanwhile, the adversary pays none of this penalty. 

A warning from the frontier 

In July 2026, an unreleased OpenAI model escaped its sandbox and compromised Hugging Face’s production infrastructure. It wasn’t an external hack, but an unintended "breakout" during testing, with its guardrails deliberately stripped for the exercise. 

The telling part came during the response. When Hugging Face tried to use its primary cloud LLM to investigate the breach, the model refused the forensic request. The "safe" model, in this context, was an obstacle. To get the analysis done, Hugging Face pivoted to an unconstrained open-weight model, GLM-5.2, which delayed their response. 

Hugging Face could make that pivot because they host open-weight models for a living and have the expertise to bypass a refusal on short notice. Most organizations don’t have that muscle. If your defensive model refuses a task mid-crisis, you’ve handed the adversary the advantage. 

That asymmetry is already being exploited. After state-sponsored actors were banned from frontier APIs, they simply moved their research to self-hosted, unconstrained models. The rise of AI-driven attacks is old news by now; what’s new is how lopsided this is about to become, with defenders slowed by refusals while adversaries are iterating at machine speed with nothing in their way. 

Guardrail asymmetry 

Attackers don’t even need to jailbreak anything. Models like GLM-5.2 and Kimi k3 are readily available with far fewer restrictions than Western frontier APIs, and "abliteration" (stripping the safety training out of an existing model) remains an option for anyone who wants to go further. Mostly, they don’t have to. They can just pick a model that doesn’t refuse them. 

Most defenders don’t have that option. Cloud APIs are tuned toward a kind of cyber do-no-harm designed to keep bad guys from using them to build attacks. This is the same refusal bias that ends up blocking security teams trying to analyze those attacks. In a defensive context, erring on caution often means erring in the attacker’s favor. Every refused request costs the defender the one resource they can’t get back: time. 

This trade-off used to be worth it. A few months ago, frontier models were far enough ahead on reasoning and code generation that the friction from their guardrails was a fair price. But the newest frontier models, like Anthropic’s Fable, are shipping with sharper cyber capabilities and even tighter guardrails to match. Meanwhile, open-weight alternatives have closed most of the reasoning gap that used to justify putting up with those guardrails in the first place. 

Either way, the calculus is shifting: Defenders are increasingly paying for restrictions without getting a capability edge in return. 

Defining operational sovereignty 

The way out is what I’d call operational sovereignty — not to be confused with data sovereignty, which is about where your data lives and how it’s treated. Operational sovereignty is about who gets the final say over what your AI is allowed to do. 

A sovereign SOC needs its AI technology to be at least on par with that of their adversaries. They either need to have a fallback on hand when their model refuses to complete a task or to use a model that will not offer refusals in the first place. That does not mean there should be no safeguards placed around the models, just that the safeguards should be under the control of the organization itself rather than imposed upon them from the outside. 

Security operations also shouldn’t be hostage to a vendor’s shifting alignment policy, or frequent behind-the-scenes model updates that may change behavior subtly and unexpectedly (known as model drift). Operational sovereignty means a policy change in Silicon Valley doesn’t quietly break your defensive workflow overnight. It’s what lets you keep pace with an adversary who was never bound by those policies to begin with. 

The roadmap: From convenience to collective defense 

Getting there isn’t all-or-nothing. The right path depends on risk tolerance and how much infrastructure a team can realistically manage.

Private infrastructure 

The most direct route is to host the model yourself, on your own GPUs or a dedicated private cloud instance, so you own the weights and the policy outright. 

• The benefit: There’s no safety penalty because there’s no third party to impose one. You’re free to choose any model that fits your needs, guardrails included or not. 
• The downside: Physical scarcity, expertise, and high upfront cost. GPU procurement can take months, the capital outlay is steep, and running your own inference stack takes specialized talent most security teams don’t have on staff. 

Model-as-a-Service 

Model-as-a-Service splits the difference. Providers like Baseten or Together AI, or platforms like Amazon Bedrock or Microsoft Foundry, let you bring your own model to infrastructure they manage, without layering their own safety refusals on top. 

• The benefit: It removes the safety penalty while offloading the hardware burden. You get the control of private infrastructure with the scalability of the cloud. 
• The downside: Dedicated capacity that avoids provider-side filters is often in short supply. Falling back to shared clusters solves the availability problem but can reintroduce the same guardrails, and the same data-sharing concerns, you were trying to escape. 

The hybrid fallback 

The most architecturally involved option is to keep frontier cloud models for most day-to-day tasks but add an automated handling path for the rest. A gateway watches for refusals and reroutes those prompts to a smaller, unconstrained model you control. 

• The benefit: A guaranteed response with minimal upfront infrastructure investment. You stay on the cutting edge of cloud capability while neutralizing the safety penalty. 
• The downside: Keeping the fallback model’s read of a prompt consistent with the primary’s, so a refused request lands the same way with both. If the fallback is a local model, you’re also managing two systems in parallel — a smaller maintenance burden than hosting it all yourself, but not zero. 

Collective inference 

The most speculative option, and the one I find most interesting: evolving the ISAC/ISAO model into collective inference. Industry groups already share threat intelligence, so why not pool the infrastructure too? A sector could jointly fund a shared, unconstrained model, maybe even one tuned to its own threat landscape, governed by its members rather than a vendor. 

• The benefit: A community-governed "brain" as capable as any frontier model, answerable only to the defenders who fund it. 
• The downside: Governance. Members have to agree on usage and safety policy, and during a sector-wide incident, everyone would be hitting the same shared infrastructure at once.

Reclaiming the defensive advantage 

You can’t manage what you don’t measure. If an AI assistant is supposed to be a force multiplier, every refusal during a live incident multiplies by zero. Security leadership should treat those refusals as a structural failure of a non-sovereign stack, not an occasional annoyance. 

Start by auditing your refusal rate. That number is the most direct way to put a figure on the safety penalty your organization is actually paying. Once you know it, the path forward gets a lot clearer. 

The adversary has already claimed its own sovereignty, running at full throttle with no guardrails to slow them down. Defenders need to manage their safeguards to keep pace. 

• Crime script analysis is a narrative-driven technique that can be used alongside, or as an alternative to, tactics, techniques, and procedures (TTPs) — creating human-readable stories that describe attacks in a way non-technical audiences can understand. 
• By analyzing the attacker’s workflow, we can identify how AI can be used to industrialize attacks. Through considering a business email compromise (BEC) example, we demonstrate how attackers may scale the attack to target previously unprofitable victims. 
• Deconstructing an attack into discrete steps allows defenders to pinpoint intervention points where defenses can be effectively deployed, or where strategic disruption can break the script and thwart the threat actor's operation.

Effective defense against cyber attacks requires understanding how attacks are carried out and identifying where the attack can be disrupted or detected.  

Lockheed Martin’s Cyber Kill Chain was one of the earliest models to describe the steps required to conduct a cyber attack. However, its seven-step linear sequence is too rigid to apply to many attacks. 

The Attack Flow model of the MITRE ATT&CK framework allows various tactics, techniques, and procedures (TTPs) to be chained together to describe exactly how attacks are conducted, including branches and loops if necessary. The resulting graphs are comprehensive, but can be daunting to a non-technical audience. In a world of evolving threats and shrinking budgets, defenders need techniques to communicate threats to a wider audience. 

Crime script analysis (CSA) is a technique originally developed in the mid-1990s as a criminology tool to understand how crimes are committed. CSA allows us to decompose an attack into a sequence of actions, decisions, and situational requirements. Describing an attack as a narrative using everyday language not only makes the description accessible to non-technical audiences, but also to identify "choke points" where the crime can be disrupted. 

If MITRE ATT&CK TTPs describe the building blocks that comprise an attack, Attack Flow diagrams are the structural engineering blueprints showing how the blocks fit together, and CSA is the architect’s artistic impression of the finished building. Each component has their place in providing a picture of what is happening at different levels of abstraction for different audiences. 

Business email compromise as a case study 

The business email compromise (BEC) is a common scam. Someone with financial authority receives a message purporting to be from a superior in the same organization requesting an urgent payment. If the victim is fooled, payment is released to the scammer, who acts quickly to launder the money to disguise its origin before the scam is uncovered. 

In April I wrote about such an attack against a small, community sports club of which I am a member. The sum requested in the attack wasn’t large, so the reason was plausible. However, the tone of the email wasn’t quite correct. The treasurer’s suspicions were raised and the attempted fraud uncovered. 

This incident was particularly interesting because of the small scale of the attack. Historically, the research necessary to conduct the attack — the identification of the target victim, the person spoofed, the nature of the social engineering lure — has limited its scalability. Carrying out these tasks manually takes time and has meant that it has typically been conducted against larger businesses.  

The advent of AI means that the previously time-consuming preparative work can be automated. Expressing the attack as a crime script helps us understand where AI may assist the attacker and how the attack could be disrupted. 

Putting BEC in the crime script narrative 

We can imagine the crime script for the attack as follows:

Steps 1 – 4 are time consuming to perform manually, but can be automated with AI. This efficiency improvement allows an attacker to identify many targets and shifts the execution of the attack from a higher value fraud against a few targets to a lower value fraud against many targets. 

The personalization of the social engineering in Step 5 can also be conducted using AI. The attacker can generate urgent requests for payment that are relevant to the target organization and may appear credible to the victim. 

Identifying intervention points 

Considering the narrative of the attack helps with reflection on how the attack might be disrupted. Clearly, Steps 1 – 4 can be disrupted by seeding AI with fake canary organizations. These are fictitious honeypot entities that have public personas discoverable by AI agents, but otherwise serve no purpose. The source of messages sent to honeypot organizations can then be blocked, disrupting Step 6. 

Interactions with large language models (LLMs) leave traces that can be identified by security teams. While distinguishing malicious prompts from legitimate business inquiries is difficult, there is potential for AI providers to detect repeated patterns of reconnaissance and the generation of social engineering messages. This leaves Step 5 vulnerable to disruption by providers of AI systems. 

The most effective disruption point remains Step 6, the delivery mechanism. Anomalous account behavior or high volumes of outgoing mail from a single source should trigger immediate rate-limiting or reputation-based blocks by email service providers. 

The final point for intervention is with the victim at Step 7. Increased awareness of the scam helps victims recognise any potential attacks that do get through. Implementing strict processes such as requiring purchase orders that must be verified and implementing delays before payments are made can all help prevent losses. 

Conclusion 

Crime script analysis does not replace the ATT&CK framework; rather, it provides an alternative narrative format for documenting attacks. Describing threat actor activity using natural language opens the understanding of the attack to a wider audience and enables collaboration with other teams. The technique also helps defenders understand where attackers may be applying AI tools to automate processes, and spark ideas at how this might be thwarted. 

Should we let AI run our threat hunts? The debate usually splits into two camps. One says, "Yes, obviously! The sheer scale of our security telemetry is impossible for humans to deal with." The other says, "Absolutely not!  You can't trust an AI with something this important."  

The thing is, I think both are wrong, or at least incomplete.  

I've spent a long time as one of the louder voices saying that hunting is specifically a human-driven process. I created the first widely recognized definition of threat hunting back in 2015, and the version I'd have given you until very recently put a human firmly at the center of it.  

But lately I've been reconsidering the role of AI in threat hunting. So this post is, in part, me arguing with my past self.  

We're facing what I call the Hunter's Paradox: Humans can no longer keep up with the volume and velocity of security data on their own, so we need to lean on automation. But the most capable automation available, AI, is exactly the kind we can't fully trust. Both are true at once, and that tension is what I've been wrestling with for a while. We can’t resolve it cleanly by picking either side, so let's take them in turn, starting with the human element. 

Humans have a numbers problem 

So why not just keep humans in the driver's seat and call it a day? Because that math stopped working a long time ago. 

When I started in this field about 30 years ago, the conventional advice was that system administrators should read all their logs every day. It probably wasn't realistic even then, and it has been thoroughly impossible for most of my career. That's the volume problem, and it only ever compounds. There's more data than anyone can read, and there's more of it every year. 

Then there's velocity. Automated attacks already move at close to machine speed, and even human-driven intrusions routinely outpace human defenders. AI on the offensive side is making that gap wider, not narrower. 

And finally, there's capacity. This isn't the usual complaint about being under-resourced. That may still be true, but the problem is deeper than that. Volume and velocity together have pushed us to a place where it is simply not possible for humans to keep up no matter how many of us there are. If your team can still manage today, the trend line says it won't be able to for long. Even a perfectly staffed, perfectly funded team can’t beat that math forever. 

Put those three pressures together and opting out of AI isn't really an option. We can't hunt at scale without it, which lands us right back in the paradox: we need a tool we can't fully trust. 

AI doesn’t deal well with lies 

When most people think about AI and attackers, they think about prompt injection. An attacker slips instructions into something the AI will read, the AI dutifully follows them, and now your defensive tooling is working for the other team. It's real, it's a problem, and you should design with it in mind. It's also the less interesting part of the trust problem, so I'm going to acknowledge it and move on. 

The deeper issue is that attackers lie and cheat constantly, whether or not they think an AI might be watching. Deception isn't a tactic they reach for occasionally; it's the medium they operate in. Every phish, every exploit, every defense evaded is a lie that has to be believed in order to work. That has always been true, long before AI showed up. 

Pervasive deception is a real issue for AI. It’s baked into how we create LLMs: They have no concept that their training data might be deceiving them, and so when they come into the real world and deal with our dirty data, they tend to take it at face value. Not every time, maybe, but enough that their judgment is noticeably skewed even when we explicitly tell them to detect shenanigans.  Even the most accurate telemetry isn't trustworthy if it's faithfully recording a lie, and AI tends to process what it's given and believe it. 

Solving the paradox starts with a definition 

Now that we understand how deep of a hole we’re in, we can start thinking about how we might get out of it. Let’s start with the very definition of threat hunting itself. 

Back in 2015, I was the architect behind the Sqrrl threat hunting framework. I defined hunting as "any manual or machine-assisted process for identifying security incidents your automated detection systems missed." That same definition carried forward into our PEAK framework in 2023, of which I was the lead author. This has been the working definition for much of the field for a decade, though often in different words. 

That phrase right at the front, "manual or machine-assisted," is the entire reason I’ve been thinking about this so hard. What that phrase actually meant was that humans drive the hunt. Machines can assist, through analytics or machine learning or whatever tooling you had, but a person was always the one doing the hunting.  

And honestly, that was the right call at the time. But if I look back at what I was really trying to capture with that definition, the essential ingredient was never the human. It was reasoning. Humans were just the only place to get it in 2015.  

But that’s no longer the case. AI can reason now — maybe not as well as a good human analyst, but it really can reason in a way that the tools of 2015 could not. So maybe the definition should change to match what I really meant. Threat hunting might be better described as "any reasoning-driven process for identifying security incidents your automated detection systems missed."  

Reframing hunting around reasoning rather than around who's doing it feels more accurate to the original intent, and it's a lot more useful for working through the paradox. If reasoning is the point, then the question isn't whether the hunter is human or machine. It's whether there's real reasoning involved. 

If it’s really about reasoning, what does that mean? 

If we accept that AI can reason and hunting is a reasoning-driven process, then letting AI drive starts to seem… well, reasonable. 

The next big question, then, is what should that actually look like? Just saying, "AI, go find the evil!" is not a real plan. I wouldn't hand most human hunters that assignment either. Letting AI hunt responsibly takes careful planning, and more importantly it takes guardrails. At least three things matter. 

The first is tight focus. Decide deliberately which hunts you're willing to let AI drive. The procedure should be reasonably clear, but the hunt should still contain some real ambiguity. It’s the ambiguity that requires reasoning, and if there’s no reasoning at all you don't have a hunt, you have a SIEM rule. A good place to start is the pile of hunts you've run before but never quite managed to fully automate. Most teams have at least one of those sitting in a backlog. 

The second is strict guidelines. An AI agent operating in your environment is a non-human principal with credentials, and it should be treated with at least as much care as a service account: scoped access, audit trails, the ability to revoke and rotate, and never more privilege than your most junior hunter would get. You also have to decide ahead of time which actions the AI can take on its own and which it cannot. Maybe you let it quarantine a user endpoint when it's confident something is wrong. Quarantining a production server? Probably not. 

The third is graduated autonomy. Don't jump straight to full hunting independence. Let the AI act as an advisor first, then an assistant, then an operator on narrowly defined tasks, earning a little more trust at each step. Remember: Your threat actors don’t have to care about collateral damage, but you do. We’ve all heard the horror stories about AIs that deleted the production database. If your AI oversteps its boundaries, you’re more likely to actually cause incidents than to detect them. 

What stays human 

Even with all of that working well, there are still things that humans will be markedly better at for the foreseeable future, but they mostly trace back to one aspect: creativity. 

One important creative area is your hunt strategy — that is, deciding what's worth hunting for in the first place, what to prioritize, and in what order. That's running the hunt program, and it shouldn't be delegated to the AI. It can execute hunts, but it shouldn't be allowed to decide which hunts matter. 

Another important creative area is analytic novelty. Attackers are creative, so we have to be creative too, both in what we choose to look for and in how we analyze our data. The biggest payoff in hunting comes from finding the thing nobody thought to look for, and an AI's training data by definition doesn't include the attacker behavior nobody has seen yet. Lean too hard on AI to generate your hunting procedures and you'll quietly converge on well-trodden ground, leaving the truly new stuff as your blind spot.  

Put together, we almost have another guideline: Humans pick what's worth hunting and how. AI executes within those bounds. 

Where we go from here 

So, should we let AI start driving some hunts? Probably, yes, but that was never really the hard question. The hard question is how, and that's the part we have to work out together. 

I don't have all the answers, and I'm not pretending this is a finished playbook. What I'm sure of is that reframing hunting around reasoning, applying narrow focus and strict guidelines and graduated autonomy, and keeping humans firmly in charge of strategy and novelty are good things to keep in mind as we figure it out. You hunters reading this are the ones who are actually going to shape what AI hunting becomes. It’s going to be on all of us to experiment, to try things, and then to share what we’ve built — whether that's code on GitHub, a blog post, or a conference talk. The whole field gets better when we share what worked and what didn't. I'm eagerly looking forward to seeing what we come up with. 

• 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.