Bissa Scanner Exposed: AI-Assisted Mass Exploitation and Credential Harvesting

Key Takeaways

• We recently discovered an exposed server that was used for multi-victim exploitation, staging, review, and validation.
• Claude Code and OpenClaw were used as an operator-side harness supporting exploitation activity and workflow orchestration.
• We identified a large-scale React2Shell (CVE-2025-55182) operation that scanned millions of targets and confirmed 900+ successful exploits. Logs showed an automated pipeline for exploitation, hit scoring, alerting, and secret harvesting.
• The threat actor exploited victims opportunistically at scale, but post-compromise activity was not indiscriminate. Artifacts show the operator triaged access, validated stolen data, and concentrated deeper collection and follow-on activity on organizations that met a clear value threshold, particularly in the financial, cryptocurrency, and retail sectors.
• Secret harvesting was a core part of the operation, with tens of thousands of .env files yielding credentials across AI, cloud, payments, messaging, and databases. Artifacts suggest the operator was also validating and prioritizing the most useful access.
• The host also exposed Telegram-based alerting and command infrastructure tied to the broader Bissa scanner ecosystem, providing rare visibility into the operator’s notification workflow and public-facing handles.

Summary

We identified an exposed server that provided unusual visibility into a large-scale, multi-victim exploitation and collection operation. Artifacts on the host showed that Claude Code and OpenClaw were embedded in the operator’s day-to-day workflow, supporting troubleshooting, orchestration, and refinement of the collection pipeline. This AI-assisted workflow resulted in the modular platform Bissa scanner enabling a broader, structured process for exploiting targets, reviewing results, validating access, and prioritizing the most valuable victim environments.

The server contained more than 13,000 files across 150+ directories tied to exploitation, victim-data staging, credential harvesting, access validation, and operator workflow management. The contents showed that this infrastructure was not being used simply to store opportunistically stolen data, but instead supported an organized operation built to acquire access at scale and operationalize the highest-value results.

Artifacts on the host showed that React2Shell (CVE-2025-55182) was central to the operation. The workflow appeared capable of scanning millions of internet-facing targets, with logs indicating more than 900 confirmed compromises. Harvested data included large volumes of environment files and credentials spanning AI providers, cloud services, payment platforms, databases, and messaging systems. Additional scripts and local tooling suggested the operator was actively testing and sorting this access to determine which credentials, accounts, and victim datasets were most useful for follow-on activity.

The exposed server also contained victim-specific data clusters that extended well beyond credentials alone. In several cases, the recovered material included financial, payroll, HR, CRM, communications, and other business-sensitive records, indicating that the operation supported both initial exploitation and deeper post-compromise collection. While some victim environments showed direct evidence of exploitation through the scanner workflow, other clusters could not be confirmed.

The host also provided rare insight into the infrastructure and operator behind the activity. Telegram-based alerting artifacts hardcoded within the Bissa scanner harness tied the operation to a single operator, publicly identifiable by the Telegram username @BonJoviGoesHard and display name “Dr. Tube.” The operator appears to run at least two dedicated bots, @bissapwned_bot for scanner alerting and @bissa_scan_bot within the AI-control subsystem.

The infrastructure of Bissa scanner is a mature, modular operation designed to exploit targets at scale, harvest and validate secrets, and use an AI-enabled workflow to increase the efficiency of collection and triage. The evidence suggests a disciplined and long-running campaign with strong success rates: the operator built repeatable workflows for exploitation, validation, alerting, and prioritization, demonstrating not only technical competence, but a clear understanding of how to convert internet-scale scanning into reliable, high-value compromises.

Secrets

The credential haul spanned every tier of modern SaaS, with AI providers emerging as the single largest category. Dumped credentials included the following platform-related keys:

By volume, the haul was equally striking:

Victims

Next, we highlight three victims whose data was identified that went beyond secrets and tokens.

One of the victims, Victim A, generalized here as a mid-sized tax resolution and financial advisory firm. Our research found direct exploit evidence existed for this environment and that a separate staged bundle labeled as a data sample was also present on the same host. That staged dataset included Plaid tokens, linked bank-account data, IRS transcript material, ACH-related records, Twilio calls, Salesforce contacts, and case data containing SSN and DOB fields.

Another cluster of data is attributable to Victim B, generalized here as a large digital-asset, payments, and enterprise finance company, and appears to reflect authenticated Oracle Fusion REST export activity tied to supplier, invoice, purchase-order, payment-process, and bank-account data.

A separate cluster attributable to Victim C, generalized here as a mid-sized payroll, HR, and stablecoin payments platform, contained payroll, settlement, Fireblocks integration, and HRIS-related material. In both cases (Victim B/C), the initial access path remains unknown.

Adversary

Beyond the AI-control surface, the host also preserved the operator’s alerting and command channel on Telegram. Runner scripts across the Bissa scanner harness hardcoded a Telegram bot token tied to the bot @bissapwned_bot (display name “BissaPwned”, bot user ID 8798206332) alongside the destination chat ID 1609309278. Metadata lookups against the Telegram API confirmed the bot remained active. The destination itself resolved to a private chat with only two participants, the bot and a single human operator, whose public Telegram identity is the username @BonJoviGoesHard (user ID 1609309278) with display name “Dr. Tube”. The bot is brand-consistent with the rest of the operation (bissascanner, bissa_bench, bissapromax, BissaPwned). It appears distinct from the @bissa_scan_bot handle referenced in the openclaw logs, which suggests the operator runs at least two dedicated bots across the scanner and AI-control subsystems.

Each @bissapwned_bot message carries an identity header (Message ID, Date, From User ID: 8798206332, From Username: bissapwned_bot) and is delivered into the operator chat 1609309278 as the Telegram C2 notification channel for the scanner fleet. The body is one line per confirmed CVE-2025-55182 hit, structured as emoji-delimited fields. Each line distilled the victim’s identity, runtime context, privilege level, cloud posture, and recoverable secret surface into a single at-a-glance record, allowing the operator to triage hundreds of exploitation events directly from Telegram.

Capability

Bissa Scanner

The Claude project transcripts under the /bissascanner/ project show the operator using Claude Code to read the scanner codebase, understand lease and acknowledgement flow, troubleshoot misses, review benchmark output, and document the project well enough to rebuild parts of the acquisition layer.

The project outputs include Chain-of-Thought (CoT) prompts showing Claude evaluating and planning improvements for the scanner.

The openclaw logs show a local AI-control surface on the same box, including a websocket gateway, browser control, the model setting pool/claude-sonnet-4-6, and the Telegram-linked provider handle @bissa_scan_bot. Together with claude_env_fix.sh and the local AI relay databases, those artifacts show that Claude and OpenClaw were part of the working environment used to operate, troubleshoot, and extend the collection workflow.

One of the most interesting findings was a Next.js React2Shell (CVE-2025-55182) exploitation workflow built around Bissa scanner which consisted of the following:

The scanner relies on an acquirer file containing targets and a lease file defining the exploit type. These files show the operator obtaining target feeds from ZIP archives hosted on cs2.ip.thc.org, assigning the cve_2025_55182 module, and deploying a payload intended to enumerate .env files, cloud metadata, Kubernetes service account context, local credential stores, database and Redis access, cryptocurrency wallet material, and other high-value secrets. A file titled “confirmed hits” indicates that more than 900 companies were exploited through this workflow.

During our investigation, we determined that the acquirer was hosted at denemekulubum[.]com[.]tr/acquirer/, while an older, now-defunct acquirer had previously been hosted at wiprz[.]com/acquirer/.

The scanner also includes a dedicated WordPress module targeting CVE-2025-9501, an unauthenticated command injection in the W3 Total Cache plugin (versions prior to 2.8.13, CVSS 9.0). In the module we recovered, only the version-check logic was present, the RCE payload itself was not available, and we did not find evidence of successful exploitation via this module.

Data Exfiltration via S3

The operator used S3-compatible Filebase as an off-box archive for harvested victim .env files. The scanner was configured to watch its local results/ directory, batch *.env files into ZIPs, and upload them to hxxps://s3.filebase[.]com in bucket bissapromax under the archives/ prefix.

The Filebase bucket history suggests at least three storage phases: bissa in September 2025, bissa2 in November 2025, and bissapromax from December 2025 onward. Of those, only bissapromax contained recoverable archive content, tying it directly to the large-scale .env collection workflow we observed in April 2026.

The full corpus in the S3 buckets contained 400+ raw env-batch-*.zip objects and over 30,000 distinct .env filenames, spanning April 10, 2026 through April 21, 2026. Across those ZIPs we counted 65,000+ archived file entries, showing that the same victim files were re-batched and re-uploaded over time rather than staged once and discarded.

Defensive Recommendations

• Patch aggressively. Keep internet-facing applications and frameworks on a tight update cadence, and subscribe to vendor advisories so that you don’t learn about critical CVEs from an incident call.
• Treat secrets like secrets. Move production credentials out of .env files and into a real secret manager, inject them at runtime, keep lifetimes short, and scope every credential to the narrowest permission it needs.
• Shrink the blast radius. Assume the perimeter will fail. Use workload identity instead of long-lived keys, harden cloud metadata access, tighten RBAC, disable unused service-account token accounts, and never mount the container runtime socket into application workloads.
• Control egress. Route outbound traffic from application tiers through a logged proxy so a compromised host can’t quietly reach cloud metadata, payment APIs, or attacker infrastructure.
• Rotate and detect. Rotate credentials on a schedule, scan source code and built artifacts for embedded secrets, and plant canary tokens that page you the moment they’re used.
• Rehearse the response. Know which credentials can be rotated in minutes versus days, keep vendor contacts current, and run a “live production key leaked” tabletop annually; the fastest recoveries belong to the teams that drilled when nothing was on fire.

Notifications & Acknowledgments

This investigation has resulted in coordinated disclosures to numerous companies whose credentials or data were recovered from the exposed server, along with direct victim notifications and triage support. Additional disclosures will continue throughout the week, and this report is intended to provide context for organizations that are contacted as part of that process. We extend our thanks to the security and incident response teams that engaged promptly and collaboratively. Any DFIR Report customers impacted by this investigation have already received direct notice through their normal channel. Thank you to Renzon Cruz (@r3nzsec) and Zach Stanford (@svch0st) for their contributions to this report.

Disclosure & Contact

Given the sensitivity of the material recovered from this exposed server, we will not be publicly disclosing the associated IP address. Law enforcement has been engaged, and all major victims tied to this directory have been directly notified.

Need more information related to this report or want to chat? Get in Touch