Peakhour.IO - Credential Exposure

Bissa scanner and the hunt for application secrets

2026-10-22T00:00:00+11:00

An exposed application configuration file can give an intruder credentials for cloud services, payments, messaging and databases. A published investigation of the Bissa scanner describes how broad exploitation leads to secret collection and access validation. Our own review found a request marker named bissa_cve_boundary across 67 source IPs on 22 October 2026, offering a practical way to search for recurring activity.

How the Bissa workflow operates

The DFIR Report's April 2026 investigation describes a workflow built around React2Shell (CVE-2025-55182). It reports that the scanner searches internet-facing applications, exploits vulnerable targets, and then collects .env files containing credentials for AI, cloud, payment, messaging and database services. Follow-up tooling checks which credentials work and prioritizes access with greater value. The report also describes Claude Code and OpenClaw helping the operator troubleshoot, coordinate and refine the collection process, with Telegram notifications for results. The researchers reconstructed this workflow from exposed operator infrastructure. The marker in our logs gives us a search lead; identifying its operator requires additional evidence.

What the request records show

We reviewed HTTP logs from 08:00 to 11:23 AEDT on 22 October 2026. It found the marker in the Content-Type value for multipart requests. The two source addresses 35.215.139.208 and 35.213.2.73 each had requests with HTTP 200 responses. The next check for these two sources is to inspect the returned content and application logs.

The boundary parameter names the separator used between parts in a multipart body. It is a request-pattern clue that can persist as source addresses or user-agent strings change. In this sample, the same marker appeared with different client declarations, so searching the boundary alongside path and response status gives analysts another way to find related records.

The user-agent strings included Python/3.11 aiohttp/3.8.4 and Python/3.12 aiohttp/3.14.5. A Chrome 126 user-agent string also appeared. GeoIP organization labels included Google, The Constant Company and RouterHosting. These values help identify records to compare.

Use the marker to find candidate requests, then compare paths, response status, user-agent and timing. Provider labels add broad network context. This lets an analyst build a focused evidence set before deciding whether a rule should block a request or raise an alert.

A December 2025 Umbraco support thread also contains the bissa_cve_boundary string. That gives defenders an older place to search for the marker. Our guide to recognising vulnerability scanners across changing IP addresses explains how to compare request patterns across source addresses.

We found these requests while investigating the multipart traffic discussed in our PHP2Shell report. The older Umbraco report gives this marker a history stretching back before the PHP disclosures.

Protect the files and the credentials

Keep environment files, backups and repository metadata outside web-served directories. Configure both the origin and edge to deny access to sensitive paths. Include the primary .env file, backup suffixes and alternate configuration paths in deployment reviews. Include these checks in release validation so a deployment does not publish a backup alongside the live configuration. OWASP's guide to reviewing old and unreferenced files discusses how backup copies can expose credentials and source code.

When a secret may have been exposed, revoke or rotate it and review where it was used. OWASP's Secrets Management Cheat Sheet covers rotating exposed credentials and monitoring their use. Monitor requests to environment and backup paths, then compare them with authentication events on downstream services. Review whether exposed credentials had excessive permissions, disable unused accounts and check relevant service logs for follow-up activity. A WAF can block known exploit patterns and sensitive paths, while application updates address the underlying vulnerabilities. Our guide to tuning a WAF covers practical controls and review.

Observed source addresses

These source IPs sent requests containing bissa_cve_boundary during the review window:

34.1.212.165
34.1.222.89
34.7.103.220
34.26.99.252
34.65.6.231
34.79.37.185
34.79.227.19
34.80.224.185
34.81.174.226
34.105.14.173
34.118.165.147
35.187.41.240
35.189.134.239
35.192.65.236
35.194.107.148
35.196.45.0
35.196.110.183
35.204.7.231
35.206.193.48
35.206.201.46
35.206.218.173
35.213.2.73
35.213.7.240
35.213.69.245
35.213.87.236
35.213.119.33
35.215.139.208
35.215.145.83
35.215.167.171
35.223.246.134
35.232.5.44
35.233.103.194
35.236.172.48
35.243.109.51
35.245.122.12
45.32.205.118
45.76.139.160
45.77.71.57
45.77.82.159
45.77.225.79
64.176.45.104
64.176.71.20
64.177.42.195
64.177.112.216
64.177.126.251
65.20.109.164
65.20.110.253
65.20.114.174
66.135.2.244
70.34.248.35
80.240.29.16
95.179.222.141
108.61.198.98
136.66.201.20
136.70.7.252
136.86.224.157
136.119.51.159
144.172.118.88
149.28.87.17
149.28.88.68
172.86.86.97
192.248.183.92
199.247.11.20
202.182.103.216
207.148.6.134
207.148.72.68
207.246.119.104

From an exposed .env file to an SMTP login in 22 seconds

2026-10-22T00:00:00+11:00

A web request for /.env can expose credentials an application uses to connect to other services. One of our honeypots recorded a clear example on 19 October 2026. Source 45.138.12.68 requested three environment-file paths, then presented the matching decoy passwords to our SMTP service. It used the password from /.env 21.58 seconds after requesting that file.

Three disclosures, three SMTP attempts

Each file contained a different decoy SMTP password. The client then used each password in a separate SMTP login attempt. All times below are UTC on 19 October 2026, corresponding to 02:32 AEDT on 20 October.

/.env at 15:32:19.841 → SMTP AUTH at 15:32:41.421, 21.58 seconds later.
/.env.backup at 15:32:27.878 → SMTP AUTH at 15:32:44.928, 17.05 seconds later.
/.env.bak at 15:32:28.569 → SMTP AUTH at 15:32:46.176, 17.61 seconds later.

The exact password matches connected each file request to the later SMTP authentication. Our SMTP honeypot simulated successful authentication. The client sent EHLO, upgraded the connection with STARTTLS, sent EHLO again, then used AUTH to test the credentials. It followed with MAIL to begin a mail transaction. RSET was the last recorded command, resetting that transaction. We recorded no recipient or message data.

The sequence is consistent with an automated credential validator: find configuration files, extract credentials and check them against another service. During the same burst, the source also requested /.env.anthropic, /.env.openai and /.git/config, extending its search to AI-service configuration and repository metadata.

An exposed environment file can matter even when the site itself has no login page. Configuration often contains credentials for databases, mail systems, APIs or deployment tools. A successful file response can give a scanner material to test against services that are reachable separately.

Fingerprints across web and mail

The observed HTTP connection used TCP signature 1460|7|1|1|64240|0x02 and TLS JA3 a15e24f40a90d5cba676dfe012ff2d4a. The HTTP user-agent claimed Chrome 124 on Windows. The three SMTP connections had the same TCP signature and a different JA3, d39e1be3241d516b1f714bd47c2bc968.

The different TLS profiles make sense across separate protocols. The exact credential matches and issuer links establish the web-to-mail sequence; the fingerprints add context about each connection. Our guide to grouping traffic with network fingerprints explains how to use these values alongside other evidence. For broader patterns, see how to recognise vulnerability scanners across changing IP addresses.

Reduce exposure and improve detection

Keep secrets outside web-accessible directories. Use origin access rules and WAF rules to block requests for environment files, backup copies and repository metadata. OWASP's guide to reviewing old and unreferenced files describes how backup copies can expose credentials and source. Check the origin as well as the edge, since a request can reach the application through a different route than expected. Review access logs for repeated requests to common secret-file paths and correlate them with authentication events on services that use those credentials.

When a real secret may have been exposed, revoke or rotate it and review its use across every service where it was valid. OWASP's Secrets Management Cheat Sheet recommends removing exposed secrets and rotating them. For mail, correlate the affected account, source IP, AUTH and MAIL results, connection timing and follow-up commands. Keep password values out of production logs. Preserve recipient, message-submission and delivery records so you can establish how far each mail session progressed. Our guide to tuning a WAF covers practical request controls and review.