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.

Peakhour.IO - Email Security

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

Three disclosures, three SMTP attempts

Fingerprints across web and mail

Reduce exposure and improve detection