Welcome to this week’s edition of the Threat Source newsletter.  

Last week, yet another security AI tool made the rounds on social media: Shannon, a fully autonomous AI penetration testing tool created by Keygraph. It “autonomously hunts for attack vectors in your code, then uses its built-in browser to execute real exploits, such as injection attacks, and auth bypass, to prove the vulnerability is actually exploitable.” 

If you thought manual pentesters kept you busy, it looks like Shannon’s here to ensure you never run out of vulnerabilities — or questions. 

As with every new advancement in AI, social posts are popping up left and right to question Shannon’s future impact on pentesters’ job security. It goes without saying these days that among the many thoughtful questions are comments praising Shannon and bemoaning the “old days” with a few obviously canned AI slop quips, which infuriates me as an editor — I could go on for days about this, but we’re getting off-topic. Ahem. 

Shannon requires access to the application’s source code, repository layout, and AI API keys. Even as a cybersecurity novice, I know that this in itself is a major liability that organizations should investigate and weigh carefully before proceeding. In last week’s newsletter, Joe gave a passionate sermon on why feeding highly private information to an agentic engine is nine times out of ten a terrible idea. While I hope Shannon is more secure than Clawdbot, given its intended use, I encourage everyone to ask as many questions as possible about what happens to the information you provide before using it. Quoting Joe, “As disciples of security, we understand installing first and asking questions later is practically asking to get pwnt.” 

Other questions I’ve had while reading through comments and exploring the GitHub page: 

• Can you set scoping guidelines? If not, you might end up with a lot of issues that’ll take a lot of time to fix. 
• No penetration test is truly representative of attackers’ situations (e.g., attackers don’t work within billable hours or two-week schedules, and only have to find one or a set of vulnerabilities). Relying on access to source code widens the gap between simulated and real-world attacks… I guess this wasn’t a question, huh? 
• For the companies who choose to use Shannon, how are you using the report it produces to improve not only your product, but also your secure development lifecycle and your developers’ skills? Make a conscious decision: Are you going to rely on Shannon as a quick fix, or integrate it and secure development into your coding practices? 

AI-powered pentesters aren’t going away any time soon. Anthtropic’s Claude Opus 4.6 was also released last week. Unlike Shannon, they added a new layer of detection to support their team in identifying and responding to Claude cyber misuse. 

As the landscape evolves, tools like Shannon and Claude Opus 4.6 will continue to push the boundaries of what’s possible, and there will be new questions about risk, responsibility, and readiness. Whether these tools become standard or remain controversial, staying informed and vigilant is as important as ever. 

The one big thing 

Cisco Talos has uncovered a new threat actor, UAT-9921, using the advanced VoidLink framework to target mainly Linux systems. VoidLink stands out for its modular, on-demand plugin creation, auditability, and ability to evade detection, with features rarely seen in similar threats. UAT-9921 has been active since at least 2019, focusing on the technology and financial sectors, and uses advanced techniques for both compromise and stealth. 

Why do I care? 

VoidLink introduces powerful new methods for attackers to compromise, control, and hide within Linux environments, which are common in critical infrastructure and cloud services. Its ability to quickly generate customized attack tools and evade detection makes it harder for defenders to respond. The framework’s advanced stealth and lateral movement features increase the risk of undetected breaches and data theft. 

So now what? 

Update your defenses and use the Snort rules and ClamAV signature mentioned in the blog to help detect and block VoidLink activity. Strengthen Linux security, especially for cloud and IoT environments, and monitorfor unusual network activity or signs of lateral movement. Make sure endpoint detection solutions are up to date and configured to recognize the latest threats. 

Top security headlines of the week 

SolarWinds WHD attacks highlight risks of exposed apps 
Several vendors in recent days have warned of exploitation of vulnerabilities in WHD, though it’s not entirely clear which bugs are under attack. (Dark Reading, SecurityWeek) 

Ivanti EPMM exploitation widespread as governments, others targeted 
Ivanti released advisories on Jan. 29 for code injection vulnerabilities in the on-premises version of Endpoint Manager Mobile. Researchers warn the activity shows evidence of initial access brokers preparing for future attacks. (Cybersecurity Dive) 

New “ZeroDayRAT” spyware kit enables total compromise of iOS, Android devices 
Once installed, capabilities include victim and device profiling, including model, OS, country, lock status, SIM and carrier info, dual SIM phone numbers, app usage broken down by time, preview of recent SMS messages, and more. (SecurityWeek) 

European Commission probes intrusion into staff mobile management backend 
Brussels is digging into a cyber break-in that targeted the European Commission’s mobile device management systems, potentially giving intruders a peek inside the official phones carried by EU staff. (The Register) 

Can’t get enough Talos? 

Humans of Talos: Ryan Liles, master of technical diplomacy  
Amy chats with Ryan Liles, who bridges the gap between Cisco’s product teams and the third-party testing labs that put Cisco products through their paces. Hear how speaking up has helped him reshape industry standards and create strong relationships in the field. 

Knife Cutting the Edge: Disclosing a China-nexus gateway-monitoring AitM framework 
Cisco Talos uncovered “DKnife,” a fully featured gateway-monitoring and adversary-in-the-middle (AitM) framework comprising seven Linux-based implants that perform deep-packet inspection, manipulate traffic, and deliver malware via routers and edge devices. 

Talos Takes: Ransomware chills and phishing heats up 
Amy is joined by Dave Liebenberg, Strategic Analysis Team Lead, to break down Talos IR’s Q4 trends. What separates organizations that successfully fend off ransomware from those that don’t? What were the top threats facing organizations? Can we (pretty please) get a sneak peek into the 2025 Year in Review? 

Upcoming events where you can find Talos 

• Cisco Live 2026 (Feb. 9 – 13) Amsterdam, Netherlands 
• S4x26 (Feb. 23 – 26) Miami, FL  

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 41f14d86bcaf8e949160ee2731802523e0c76fea87adf00ee7fe9567c3cec610 
MD5: 85bbddc502f7b10871621fd460243fbc  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=41f14d86bcaf8e949160ee2731802523e0c76fea87adf00ee7fe9567c3cec610   
Example Filename: 85bbddc502f7b10871621fd460243fbc.exe 
Detection Name: W32.41F14D86BC-100.SBX.TG 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe  
Detection Name: Win.Dropper.Miner::95.sbx.tg** 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
Example Filename: d4aa3e7010220ad1b458fac17039c274_64_Dll.dll  
Detection Name: Auto.90B145.282358.in02 

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
MD5: aac3165ece2959f39ff98334618d10d9  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974 
Example Filename: d4aa3e7010220ad1b458fac17039c274_63_Exe.exe  
Detection Name: W32.Injector:Gen.21ie.1201 

SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55  
MD5: 41444d7018601b599beac0c60ed1bf83  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
Example Filename: content.js Detection Name: W32.38D053135D-95.SBX.TG

Cisco Talos Blog – ​Read More

Executive Summary

Cyble Research and Intelligence Labs (CRIL) observed large-scale, systematic exposure of ChatGPT API keys across the public internet. Over 5,000 publicly accessible GitHub repositories and approximately 3,000 live production websites were found leaking API keys through hardcoded source code and client-side JavaScript.

GitHub has emerged as a key discovery surface, with API keys frequently committed directly into source files or stored in configuration and .env files. The risk is further amplified by public-facing websites that embed active keys in front-end assets, leading to persistent, long-term exposure in production environments.

CRIL’s investigation further revealed that several exposed API keys were referenced in discussions mentioning the Cyble Vision platform. The exposure of these credentials significantly lowers the barrier for threat actors, enabling faster downstream abuse and facilitating broader criminal exploitation.

These findings underscore a critical security gap in the AI adoption lifecycle. AI credentials must be treated as production secrets and protected with the same rigor as cloud and identity credentials to prevent ongoing financial, operational, and reputational risk.

Key Takeaways

• GitHub is a primary vector for the discovery of exposed ChatGPT API keys.
• Public websites and repositories form a continuous exposure loop for AI secrets.
• Attackers can use automated scanners and GitHub search operators to harvest keys at scale.
• Exposed AI keys are monetized through inference abuse, resale, and downstream criminal activity.
• Most organizations lack monitoring for AI credential misuse.

AI API keys are production secrets, not developer conveniences. Treating them casually is creating a new class of silent, high-impact breaches.

Richard Sands, CISO, Cyble

Overview, Analysis, and Insights

“The AI Era Has Arrived — Security Discipline Has Not”

We are firmly in the AI era. From chatbots and copilots to recommendation engines and automated workflows, artificial intelligence is no longer experimental. It is production-grade infrastructure with end-to-end workflows and pipelines. Modern websites and applications increasingly rely on large language models (LLMs), token-based APIs, and real-time inference to deliver capabilities that were unthinkable just a few years ago.

This rapid adoption has also given rise to a development culture often referred to as “vibe coding.” Developers, startups, and even enterprises are prioritizing speed, experimentation, and feature delivery over foundational security practices. While this approach accelerates innovation, it also introduces systemic weaknesses that attackers are quick to exploit.

One of the most prevalent and most dangerous of these weaknesses is the widespread exposure of hardcoded AI API keys across both source code repositories and production websites.

A rapidly expanding digital risk surface is likely to increase the likelihood of compromise; a preventive strategy is the best approach to avoid it. Cyble Vision provides users with insight into exposures across the surface, deep, and dark web, generating real-time alerts for them to view and take action.

SOC teams will be able to leverage this data to remediate compromised credentials and their associated endpoints. With Threat Actors potentially weaponizing these credentials to carry out malicious activities (which will then be attributed to the affected user(s)), proactive intelligence is paramount to keeping one’s digital risk surface secure.

“Tokens are the new passwords — they are being mishandled.”

AI platforms use token-based authentication. API keys act as high-value secrets that grant access to inference capabilities, billing accounts, usage quotas, and, in some cases, sensitive prompts or application behavior. From a security standpoint, these keys are equivalent to privileged credentials.

Despite this, ChatGPT API keys are frequently embedded directly in JavaScript files, front-end frameworks, static assets, and configuration files accessible to end users. In many cases, keys are visible through browser developer tools, minified bundles, or publicly indexed source code. An example of the keys hardcoded in popular reputable websites is shown below (see Figure 1)

This reflects a fundamental misunderstanding: API keys are being treated as configuration values rather than as secrets. In the AI era, that assumption is dangerously outdated. In some cases, this happens unintentionally, while in others, it’s a deliberate trade-off that prioritizes speed and convenience over security.

When API keys are exposed publicly, attackers do not need to compromise infrastructure or exploit vulnerabilities. They simply collect and reuse what is already available.

CRIL has identified multiple publicly accessible websites and GitHub Repositories containing hardcoded ChatGPT API keys embedded directly within client-side code. These keys are exposed to any user who inspects network requests or application source files.

A commonly observed pattern resembles the following:

```javascript
const OPENAI_API_KEY = "sk-proj-XXXXXXXXXXXXXXXXXXXXXXXX";
```

```javascript
const OPENAI_API_KEY = "sk-svcacct-XXXXXXXXXXXXXXXXXXXXXXXX";
```

The prefix “sk-proj-“ typically represents a project-scoped secret key associated with a specific project environment, inheriting its usage limits and billing configuration. The “sk-svcacct-“ prefix generally denotes a service account–based key intended for automated backend services or system integrations.

Regardless of type, both keys function as privileged authentication tokens that enable direct access to AI inference services and billing resources. When embedded in client-side code, they are fully exposed and can be immediately harvested and misused by threat actors.

GitHub as a High-Fidelity Source of AI Secrets

Public GitHub repositories have emerged as one of the most reliable discovery surfaces for exposed ChatGPT API keys. During development, testing, and rapid prototyping, developers frequently hardcode OpenAI credentials into source code, configuration files, or .env files—often with the intent to remove or rotate them later. In practice, these secrets persist in commit history, forks, and archived repositories.

CRIL analysis identified over 5,000 GitHub repositories containing hardcoded OpenAI API keys. These exposures span JavaScript applications, Python scripts, CI/CD pipelines, and infrastructure configuration files. In many cases, the repositories were actively maintained or recently updated, increasing the likelihood that the exposed keys were still valid at the time of discovery.

Notably, the majority of exposed keys were configured to access widely used ChatGPT models, making them particularly attractive for abuse. These models are commonly integrated into production workflows, increasing both their exposure rate and their value to threat actors.

Once committed to GitHub, API keys can be rapidly indexed by automated scanners that monitor new commits and repository updates in near real time. This significantly reduces the window between exposure and exploitation, often to hours or even minutes.

Public Websites: Persistent Exposure in Production Environments

Beyond source code repositories, CRIL observed widespread exposure of ChatGPT API keys directly within production websites. In these cases, API keys were embedded in client-side JavaScript bundles, static assets, or front-end framework files, making them accessible to any user inspecting the application.

CRIL identified approximately 3,000 public-facing websites exposing ChatGPT API keys in this manner. Unlike repository leaks, which may be removed or made private, website-based exposures often persist for extended periods, continuously leaking secrets to both human users and automated scrapers.

These implementations frequently invoke ChatGPT APIs directly from the browser, bypassing backend mediation entirely. As a result, exposed keys are not only visible but actively used in real time, making them trivial to harvest and immediately abuse.

As with GitHub exposures, the most referenced models were highly prevalent ChatGPT variants used for general-purpose inference, indicating that these keys were tied to live, customer-facing functionality rather than isolated testing environments. These models strike a balance between capability and cost, making them ideal for high-volume abuse such as phishing content generation, scam scripts, and automation at scale.

Hard-coding LLM API keys risks turning innovation into liability, as attackers can drain AI budgets, poison workflows, and access sensitive prompts and outputs. Enterprises must manage secrets and monitor exposure across code and pipelines to prevent misconfigurations from becoming financial, privacy, or compliance issues.  

Kautubh Medhe, CPO, Cyble

From Exposure to Exploitation: How Attackers Monetize AI Keys

Threat actors continuously monitor public websites, GitHub repositories, forks, gists, and exposed JavaScript bundles to identify high-value secrets, including OpenAI API keys. Once discovered, these keys are rapidly validated through automated scripts and immediately operationalized for malicious use.

Compromised keys are typically abused to:

• Execute high-volume inference workloads
• Generate phishing emails, scam scripts, and social engineering content
• Support malware development and lure creation
• Circumvent usage quotas and service restrictions
• Drain victim billing accounts and exhaust API credits

In certain cases, CRIL, using Cyble Vision, also identified several of these keys that originated from exposures and were subsequently leaked, as noted in our spotlight mentions. (see Figure 2 and Figure 3)

Unlike traditional conventions, AI API activity is often not integrated into centralized logging, SIEM monitoring, or anomaly detection frameworks. As a result, malicious usage can persist undetected until organizations encounter billing spikes, quota exhaustion, degraded service performance, or operational disruptions.

Conclusion

The exposure of ChatGPT API keys across thousands of websites and tens of thousands of GitHub repositories highlights a systemic security blind spot in the AI adoption lifecycle. These credentials are actively harvested, rapidly abused, and difficult to trace once compromised.

As AI becomes embedded in business-critical workflows, organizations must abandon the perception that AI integrations are experimental or low risk. AI credentials are production secrets and must be protected accordingly.

Failure to secure them will continue to expose organizations to financial loss, operational disruption, and reputational damage.

SOC teams should take the initiative to proactively monitor for exposed endpoints using monitoring tools such as Cyble Vision, which provides users with real-time alerts and visibility into compromised endpoints.

This, in turn, allows them to take corrective action to identify which endpoints and credentials were compromised and secure any compromised endpoints as soon as possible.

Our Recommendations

Eliminate Secrets from Client-Side Code

AI API keys must never be embedded in JavaScript or front-end assets. All AI interactions should be routed through secure backend services.

Enforce GitHub Hygiene and Secret Scanning

• Prevent commits containing secrets through pre-commit hooks and CI/CD enforcement
• Continuously scan repositories, forks, and gists for leaked keys
• Assume exposure once a key appears in a public repository and rotate immediately
• Maintain a complete inventory of all repositories associated with the organization, including shadow IT projects, archived repositories, personal developer forks, test environments, and proof-of-concept code
• Enable automated secret scanning and push protection at the organization level

Apply Least Privilege and Usage Controls

• Restrict API keys by project scope and environment (separate dev, test, prod)
• Apply IP allowlisting where possible
• Enforce usage quotas and hard spending limits
• Rotate keys frequently and revoke any exposed credentials immediately
• Avoid sharing keys across teams or applications

Implement Secure Key Management Practices

• Store API keys in secure secret management systems
• Avoid storing keys in plaintext configuration files
• Use environment variables securely and restrict access permissions
• Do not log API keys in application logs, error messages, or debugging outputs
• Ensure keys are excluded from backups, crash dumps, and telemetry exports

Monitor AI Usage Like Cloud Infrastructure

Establish baselines for normal AI API usage and alert on anomalies such as spikes, unusual geographies, or unexpected model usage.

The post When AI Secrets Go Public: The Rising Risk of Exposed ChatGPT API Keys appeared first on Cyble.

Cyble – ​Read More

In enterprise SaaS, unclear security decisions carry real cost. False positives disrupt customers, while missed threats expose the business. 

A Fortune 500 cloud provider addressed this risk by embedding ANY.RUN into SOC investigations, giving analysts the behavioral evidence needed to reduce escalations, improve triage confidence, and make proportionate response decisions at scale. 

Company Context and Security Scope 

The organization is a Fortune 500 enterprise SaaS provider headquartered in North America, supporting enterprise customers across multiple regions and regulatory environments, with a workforce in the tens of thousands. 

• Industry: Enterprise cloud software and SaaS, where customers expect strong security, high availability, and strict data protection. 

• Environment: Not endpoint-centric; security coverage spans a large multi-tenant SaaS platform, internal corporate environments, and a broad ecosystem of integrations, partners, and third-party access, each introducing distinct threat characteristics 

• Security organization: A mature, multi-tier structure with dedicated SOC, incident response, threat hunting, and security engineering functions operating across regions. 

Core Challenges: Volume, Ambiguity, and Escalation Friction 

When we spoke with the security engineer, we expected the usual story, missing visibility, gaps in tooling, not enough telemetry. But the discussion quickly showed the real problem was somewhere else. 

The issue wasn’t seeing what was happening. The team already had plenty of signals coming in every day: authentication events, API activity, admin actions, and a constant flow of partner and integration traffic. The issue was that most of it was legitimate, which made the dangerous moments harder to prove early. 

On the surface, nothing looked wrong. But unclear alerts were consuming more and more of our time. We were drowning in uncertainty. For a company serving global customers, that level of ambiguity wasn’t acceptable.

During our discussion, it became clear that the pressure point was volume + ambiguity. 

Defining the Right Direction for Triage and Response 

Once we clarified the challenges, the priority became clear: make early triage decisions more certain, without increasing operational risk in a multi-tenant SaaS environment. 

The team focused on: 

• Reducing uncertainty during triage 

• Improving confidence in early-stage decisions 

• Separating isolated external issues from broader attack patterns and benign platform behavior 

• Supporting proportional response, not aggressive automation 

Solution: Behavior-Based Evidence in Early Investigations 

To reach the clarity they were aiming for, the team needed a way to introduce reliable behavioral evidence into early-stage investigations, without disrupting existing SOC workflows or forcing premature automation. 

ANY.RUN closed this gap by giving analysts a safe way to observe the real behavior behind a suspicious file or link, replacing guesswork based on reputation, static indicators, or incomplete external signals with direct, controlled evidence. 

The biggest change was moving from ‘this looks suspicious’ to ‘this is what it actually does.’ That kind of controlled, repeatable proof is what makes confident decisions possible, especially when threats originate outside your perimeter.

Rather than accelerating response blindly, this approach helped the SOC make earlier, calmer, and more proportional decisions within the same operational model. 

Process Impact: Phishing and External Threat Triage 

Phishing was one of the clearest use cases for the new approach. Many alerts weren’t obviously malicious, but they couldn’t be ignored either, especially when they involved links, attachments, or multi-step redirected flows coming from outside the company’s perimeter. 

With behavior-based validation provided by ANY.RUN sandbox, Tier-1 no longer had to rely on “looks suspicious” signals to make the first call. Analysts could safely interact with artifacts, observe what actually happened, and capture the full chain; redirects, credential capture, payload delivery, or follow-on behavior. 

In practice, this made a visible difference: in roughly 90% of cases, analysts were able to surface the full attack chain within about 60 seconds, turning unclear alerts into evidence-backed decisions early in the workflow. 

A big part of the improvement came also from automated interactivity. Instead of spending time manually clicking through steps that attackers use to slow investigations, CAPTCHAs, multi-hop redirects, or links hidden behind QR codes, analysts could let the sandbox mimic user behavior and capture the full sequence safely. That meant faster verdicts, less friction, and more confidence at Tier-1 without relying on guesswork. 

These shifts improved day-to-day operations: 

• More cases closed confidently at Tier-1 when behavior was clearly benign or clearly malicious 

• Escalations became more intentional, with evidence attached instead of uncertainty 

• Tier-2 spent less time on basic confirmation and more time on true incident work 

• Triage became more consistent across regions and shifts 

Expanding Context with Threat Intelligence 

While behavioral evidence clarified what a threat does, the team also needed faster answers to what it means in the broader landscape. 

To close that gap, they decided to extend their workflow with ANY.RUN’s Threat Intelligence capabilities, adding immediate context to artifacts discovered during triage. 

Threat Intelligence Lookup helped analysts quickly determine: 

• Whether infrastructure was linked to known campaigns 

• If observed behavior matched publicly reported threats 

• How relevant an external signal was to their specific environment 

We notice how our threat hunting is getting more grounded and faster to validate. When a hunt intersects with external artifacts, phishing payloads, suspicious links, or malware samples, we can confirm the behavior and enrich the hypothesis quickly, instead of spending time on patterns that stay theoretical.

At the same time, Threat Intelligence Feeds delivered behavior-verified indicators that could be correlated inside existing detection and monitoring pipelines, strengthening visibility without adding noise. 

Together, these solutions allowed the SOC to move from isolated alert handling toward context-aware investigation, where decisions were supported not only by observed behavior, but also by real-world threat activity. 

We started using TI Feeds as an enrichment layer on top of our existing threat intelligence stack. What stood out for us is that the indicators are tied to sandbox-verified behavior, so we’re not reacting to blind IOCs, we’re adding context we can actually trust. 

As a result, analysts spent less time searching for background information and more time responding with clarity and confidence. 

Measurable Improvements Across SOC Operations 

As the new workflow stabilized, the team began to see consistent improvements across investigation quality, escalation patterns, and overall SOC efficiency: 

What SOC Managers Reported After the Workflow Shift 

Beyond individual investigations, SOC managers began to notice improvements in how decisions were communicated, reviewed, and justified across the organization.  

With clearer behavioral evidence and immediate threat context, plus auto-generated investigation reports and built-in collaboration capabilities, updates to stakeholders became more straightforward, and post-incident analysis required far less backtracking. 

Cases were easier to standardize across regions and shifts because the same evidence, context, and artifacts were captured and shared in a consistent way. Escalations increasingly arrived with supporting proof rather than open questions, which reduced “back-and-forth” and helped keep response actions proportional to real risk. 

From a manager’s perspective, the biggest change was consistency. Decisions were easier to stand behind because the evidence and reporting were already there, and teams could collaborate on the same case without losing context.

Importantly, this progress didn’t require changing the overall security strategy. Instead, it reduced friction inside an already mature SOC model, helping ensure that when action was taken, it was taken for the right reasons. 

Conclusion: From Uncertainty to Confident, Proportional Response 

By embedding ANY.RUN into daily SOC operations, this Fortune 500 SaaS provider reduced ambiguity in early triage and strengthened decision-making across the entire workflow. 

We just stopped losing time to uncertainty. Now we can confirm what’s happening faster and escalate only when it actually makes sense.

With behavioral evidence, immediate threat context, and consistent reporting built into investigations, the SOC became more predictable, more efficient, and better aligned with the need for proportional response at enterprise scale. 

About ANY.RUN 

ANY.RUN is part of modern SOC workflows, integrating into existing processes and strengthening the full operational cycle across Tier 1, Tier 2, and Tier 3. 

It supports every stage of investigation; from exposing real behavior through safe detonation, to enriching findings with broader threat context, to delivering continuous intelligence that helps teams move faster and make confident decisions. 

Today, more than 600,000 security professionals and 15,000 organizations rely on ANY.RUN to accelerate triage, reduce unnecessary escalations, and stay ahead of evolving phishing and malware campaigns. 

Check how ANY.RUN can improve investigation clarity and speed in your SOC 

Frequently Asked Questions

The post Fortune 500 Tech Enterprise Speeds up Triage and Response with ANY.RUN’s Solutions appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

RESEARCH DISCLAIMER:  
This analysis examines the most recent and actively maintained repositories of OTP & SMS bombing tools to understand current attack capabilities and targeting patterns. All statistics represent observed patterns within our research sample and should be interpreted as indicative trends rather than definitive totals of the entire OTP bombing ecosystem. The threat landscape is continuously evolving with new tools and repositories emerging regularly. 

Executive Summary

Cyble Research and Intelligence Labs (CRIL) identified sustained development activity surrounding SMS, OTP, and voice-bombing campaigns, with evidence of technical evolution observed through late 2025 and continuing into 2026. Analysis of multiple development artifacts reveals progressive expansion in regional targeting, automation sophistication, and attack vector diversity.

Recent activity observed through September and October 2025, combined with new application releases in January 2026, indicates ongoing campaign persistence. The campaigns demonstrate technical maturation from basic terminal implementations to cross-platform desktop applications with automated distribution mechanisms and advanced evasion capabilities.

CRIL’s investigation identified coordinated abuse of authentication endpoints across the telecommunications, financial services, e-commerce, ride-hailing, and government sectors, collectively targeting infrastructure in West Asia, South Asia, and Eastern Europe.

Key Takeaways

• Persistent Evolution: Repository modifications observed through late 2025, with new regional variants released in January 2026
• Cross-Platform Advancement: Transition from terminal tools to Electron-based desktop applications with GUI and auto-update mechanisms
• Multi-Vector Capabilities: Combined SMS, OTP, voice call, and email bombing, enabling sustained harassment campaigns
• Performance Optimization: Implementation in Go, claiming significant speed advantages with FastHTTP library integration
• Advanced Evasion: Proxy rotation, User-Agent randomization, request timing variation, and concurrent execution capabilities (75% SSL bypass prevalence)
• Broad Infrastructure Exposure: ~843 authentication endpoints across ~20 repositories spanning multiple industry verticals
• Low Detection Rates: Multi-stage droppers and obfuscation techniques evade antivirus detection at the time of analysis

Discovery and Attribution

What began in the early 2020s as isolated pranks among tech-savvy individuals has evolved into a sophisticated ecosystem of automated harassment tools. SMS bombing – the practice of overwhelming a phone number with a barrage of automated text messages – initially emerged as rudimentary Python scripts shared on coding forums.

These early implementations were crude, targeting only a handful of regional service providers and using manually collected API endpoints. Given the dramatic transformation of the digital threat landscape in recent years, driven by the proliferation of public code repositories, the commoditization of attack tools, and the increasing sophistication of threat actors.

Our investigation into this evolving threat began with routine monitoring of malicious code repositories and underground discussion forums. What we discovered was far more extensive: a well-organised, rapidly expanding ecosystem characterized by cross-platform tool development, international collaboration among threat actors, and an alarming trend toward commercialization.

Repository Analysis and Dataset Composition

Malicious actors have weaponised GitHub as a distribution platform for SMS and OTP-bombing tools, creating hundreds of malicious repositories since 2022. Our investigation analyzed around 20 of the most active and recently maintained repositories to characterize current attack capabilities.

Across these repositories, there are ~843 vulnerable, catalogued  API endpoints from legitimate organizations: e-commerce platforms, financial institutions, government services, and telecommunications providers.

Each endpoint lacks adequate rate limiting or CAPTCHA protection, enabling automated exploitation. Target lists span seven geographic regions, with concentrated focus on India, Iran, Turkey, Ukraine, and Eastern Europe.

Repository maintainers provide tools in seven programming languages and frameworks, from simple Python scripts to cross-platform GUI applications. This diversity enables attackers with minimal technical knowledge to execute harassment campaigns without understanding the underlying exploitation mechanics.

Attack Ecosystem: By The Numbers

Our analysis of active SMS bombing repositories gives us an insight into the true scale and sophistication of this threat landscape:

Regional Targeting Distribution

Iran-focused endpoints dominate the observed sample at 61.68% (~520 endpoints), followed by India at 16.96% (~143 endpoints). This concentration suggests coordinated development efforts targeting specific telecommunications infrastructure.

Web-Based SMS Bombing Services

Accessibility and Threat Escalation

In parallel with the open-source repository ecosystem, a thriving commercial sector of web-based SMS-bombing services exists.

These platforms represent a significant escalation in threat accessibility, removing all technical barriers to conducting attacks. Unlike repository-based tools that require users to download code, configure environments, and execute commands, these web services offer point-and-click interfaces accessible from any browser or mobile device.

Deceptive Marketing Practices

Our analysis identified numerous active web services operating openly via search-engine-indexed domains. These services employ sophisticated marketing strategies, positioning themselves as ‘prank tools’ or ‘SMS testing services’ while providing the exact functionality required for harassment campaigns.

Data Harvesting and Resale Operations

Although these websites present themselves as benign prank tools, they operate a predatory data-collection model in which users’ phone numbers are systematically harvested for secondary exploitation. These collected contact numbers are subsequently used for spam campaigns and scam operations, or monetized through resale as lead lists to third-party spammers and scammers. This creates a dual-threat model: users inadvertently expose both their targets and themselves to ongoing spam victimization, while platform operators profit from both service fees and the commodification of harvested contact data.

Technical Analysis

Attack Methodology

SMS bombing attacks follow a predictable workflow that exploits weaknesses in API design and implementation.

Phase 1: API Discovery

Attackers identify vulnerable OTP endpoints through multiple techniques:

• Manual Testing: Identifying login pages and registration forms that trigger SMS verification
• Automated Scanning: Using tools to probe common API paths like /api/send-otp, /verify/sms, /auth/send-code
• Source Code Analysis: Examining mobile applications and web applications for hardcoded API endpoints
• Shared Intelligence: Leveraging community-maintained lists of vulnerable endpoints on forums and GitHub

Industry Sector Targeting Patterns

Our analysis reveals systematic targeting across multiple industry verticals, with telecommunications and authentication services comprising nearly half of all observed endpoints.

Phase 2: Tool Configuration

Modern SMS bombing tools require minimal setup:

• Multi-threading: Simultaneous requests to multiple APIs
• Proxy Support: Rotation of IP addresses to evade rate limiting
• Randomization: Variable delays between requests to appear more legitimate
• Persistence: Automatic retry mechanisms and error handling
• Reporting: Real-time statistics on successful message deliveries

Attacker Technology Stack Evolution

A detailed analysis of the ~20 repositories reveals significant technical sophistication and platform diversification:

Phase 3: Attack Execution

Once configured, the tool initiates a flood of legitimate-looking API requests.

Attack Vector Prevalence Analysis

Our analysis reveals the distribution of attack methods across the ~843 observed endpoints:

Technical Sophistication: Evasion Techniques

Analysis of the ~20 repositories reveals widespread adoption of anti-detection measures designed to bypass common security controls.

Impact Assessment

Individual Users

For end users targeted by SMS bombing attacks, the consequences include:

Impact Type	Description
Device Overload	Hundreds or thousands of incoming messages degrade device performance.
Communication Disruption	Legitimate messages are buried under spam, potentially leading to missed important notifications.
Inbox Capacity	SMS storage limits reached, preventing the receipt of new messages.
Battery Drain	Constant notifications deplete the affected device’s battery.
MFA Fatigue	Overwhelming authentication requests create security blind spots.
Data Harvesting	Prank sites for SMS bombing likely sell or reuse data for fraud or scams.

Organizations

Businesses whose APIs are exploited face multiple challenges:

Impact Category	Impact Type	Details
Financial Impact	Cost per OTP SMS	$0.05 to $0.20 per message
	Attack cost (10,000 messages)	$500 to $2,000 per attack
	Unprotected endpoints	Monthly bills can escalate to significant high amounts.
Operational Impact	User access issues	Legitimate users are unable to receive verification codes
	Customer service	Overwhelmed with complaints
	SMS delivery	Delays affecting all customers
	Regulatory compliance	Potential violations if users cannot access accounts
Reputational Impact	Media coverage	Negative social media coverage
	Customer trust	Erosion of customer confidence
	Brand damage	Association with spam and poor security
	Competitive position	Potential loss of business to competitors

Mitigation Strategies: Evidence-Based Recommendations

Based on analysis of successful bypass techniques across ~20 repositories, the following mitigation strategies are prioritized by effectiveness against observed attack patterns. Implementation of these controls addresses the primary exploitation vectors identified in our research.

For Service Providers (API Owners)

CRITICAL Priority

1. Implement Comprehensive Rate Limiting
Rationale	67% of targeted endpoints lack basic rate controls
Implementation	Per-IP Limiting: Maximum 5 OTP requests per hour. Per-Phone Limiting: Maximum 3 OTP requests per 15 minutes. Per-Session Limiting: Maximum 10 total verification attempts
Evidence	Would have blocked 81% of observed attack patterns

2. Deploy Dynamic CAPTCHA
Rationale	33% of tools exploit hardcoded reCAPTCHA tokens
Implementation	Use reCAPTCHA v3 with dynamic scoring. Rotate site keys regularly. Implement challenge escalation for suspicious behaviour
Evidence	Static CAPTCHA is defeated in most of the repositories

3. SSL/TLS Verification Enforcement
Rationale	75% of tools disable certificate validation to bypass security controls
Implementation	Enable HSTS (HTTP Strict Transport Security) headers, implement certificate pinning for mobile applications. Monitor and alert on certificate validation errors
Evidence	The most common evasion technique observed across repositories

HIGH Priority

Control	Rationale	Implementation Guidance
4. User-Agent Validation	58.3% of tools randomize User-Agent headers to evade detection	Maintain a whitelist of legitimate clients. Cross-validate User-Agent with other headers Flag mismatched browser/OS combinations
5. Request Pattern Analysis	Automated tools exhibit consistent timing patterns, unlike human behavior	Maintain a whitelist of legitimate clients. Cross-validate User-Agent with other headers. Flag mismatched browser/OS combinations
6. Phone Number Validation	Prevents abuse of number generation algorithms and invalid targets	Monitor for sub-100-ms request interval. Detect sequential API endpoint testing. Flag multiple failed CAPTCHA attempts

For Enterprises (API Consumers)

Mitigation Area	Recommended Actions
SMS Cost Monitoring	Set spending alerts at $100, $500, and $1,000 thresholds. Review daily SMS volumes for anomalies. Identify and investigate anomalous spikes immediately
Multi-Factor Authentication Hardening	Mandate rate-limiting requirements in service-level agreements Require CAPTCHA implementation on all OTP endpoints Request monthly security and abuse reports. Include SMS abuse liability clauses in contracts
Vendor Security Requirements	Mandate rate-limiting requirements in service-level agreements. Require CAPTCHA implementation on all OTP endpoints. Request monthly security and abuse reports. Include SMS abuse liability clauses in contracts

For Individuals

Protection Area	Recommended Actions
Number Protection	Document attack timing, volume, and sender information File police reports for harassment or threats. Request carrier assistance in blocking source numbers. Monitor all accounts for unauthorized access attempts
MFA Best Practices	Document attack timing, volume, and sender information. File police reports for harassment or threats. Request carrier assistance in blocking source numbers. Monitor all accounts for unauthorized access attempts
Incident Response	Prefer authenticator apps (Google Authenticator, Authy) over SMS Never approve unexpected or unsolicited MFA prompts. Contact the service provider immediately if SMS bombing occurs

Conclusion

The SMS/OTP bombing threat landscape has matured significantly between 2023 and 2026, evolving from simple harassment tools into sophisticated attack platforms with commercial distribution. Our analysis of ~20 repositories containing ~843 endpoints reveals systematic targeting across multiple industries and regions, with concentration in Iran (61.68%) and India (16.96%).

The emergence of Go-based high-performance tools, cross-platform GUI applications, and Telegram bot interfaces indicates the professionalization of this attack vector. With 75% of analyzed tools implementing SSL bypass and 58% using User-Agent randomization, defenders face sophisticated adversaries simultaneously employing multiple evasion techniques.

Organizations must prioritize comprehensive rate limiting, dynamic CAPTCHA implementation, and robust monitoring to achieve the projected 85%+ attack prevention effectiveness. The financial impact—potentially exceeding $50,000 monthly for unprotected endpoints—justifies immediate investment in defensive measures.

As the ecosystem continues to evolve, continuous monitoring of underground forums, repository activity, and emerging attack patterns remains essential for maintaining effective defenses against this persistent threat.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Technique Name
Initial Access	T1190	Exploit Public-Facing Application
Execution	T1059.006	Command and Scripting Interpreter
Defense Evasion	T1036.005	Masquerading: Match Legitimate Name or Location
Defense Evasion	T1027	Obfuscated Files or Information
Defense Evasion	T1553.004	Subvert Trust Controls: Install Root Certificate
Defense Evasion	T1090.002	Proxy: External Proxy
Credential Access	T1110.003	Brute Force: Password Spraying
Credential Access	T1621	Multi-Factor Authentication Request Generation
Impact	T1499.002	Endpoint Denial of Service: Service Exhaustion Flood
Impact	T1498.001	Network Denial of Service: Direct Network Flood
Impact	T1496	Resource Hijacking

The post SMS & OTP Bombing Campaigns: Evolving API Abuse Targeting Multiple Regions appeared first on Cyble.

Cyble – ​Read More