Proxyshell Test
You run a proxyshell test by checking how your mail server handles web path routing. This check confirms if a user can bypass login checks to run admin commands. Security teams often start this review by scanning public endpoints and checking patch levels. They also review which service accounts hold broad mail export permissions. When those service roles have too much power, one flaw exposes the whole system. A simple path bug can let an attacker read mailboxes or write files. How a proxyshel
Test: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run a proxyshell test by checking how your mail server handles web path routing. This check confirms if a user can bypass login checks to run admin commands. Security teams often start this review by scanning public endpoints and checking patch levels. They also review which service accounts hold broad mail export permissions. When those service roles have too much power, one flaw exposes the whole system. A simple path bug can let an attacker read mailboxes or write files.
How a proxyshell test works in practice
The flaw combines three distinct bugs inside the mail server web client interface. First, the front-end service misreads the URL path and forwards requests to the back-end. This URL confusion lets an outside request reach internal server interfaces without a login. Second, the back-end service trusts the front-end and elevates the user role. The system maps the request to an admin token with high privileges. Third, that admin role allows the user to export mail data to a file. During a proxyshell test, a scanner checks if the server rejects malformed path requests. A patched server blocks the path trick at the front door. An unpatched server returns a status code that shows the back-end responded. Teams also review the role rules assigned to the mail export system. In many setups, the default admin role can write files to local web folders. If a test succeeds, it proves the path check failed and roles are broad.
What native patching fixes and what gaps remain
Applying the vendor patch fixes the URL parser and blocks the login bypass. Role cleanup also helps by removing mail export rights from standard admin accounts. These native steps stop outside attackers from using this specific chain of bugs. Still, server patches and static role rules only decide who can log in. They do not inspect what individual commands or queries do during an active session. Legitimate admins still need high privileges to fix mail queues and manage user accounts. Once an engineer logs into the host, the native system trusts every command. A careless command can still dump user emails or phone numbers to a disk. Also, shared admin keys and local scripts often stay on the server for months. Native server logs rarely capture every single shell input and output in one place. If a bad actor steals a valid admin key, patch levels will not help. Teams still need a way to check each command in flight and mask fields. Rewriting matched fields like card numbers or national IDs in results reduces data risk.
Steps to verify your server after a check
After you finish your scan, you should check the server state right away. Start by reading the web server logs for strange URL strings and status codes. Look for requests that hit the autodiscover path from unknown outside network addresses. Next, check the role assignments for the mail export group in your directory. Remove any user or service account that does not need daily export rights. You should also check local web folders for new files created by system accounts. Rotate all admin passwords and service keys that live on that mail host. Finally, run a second check to confirm the new rules block bad requests. Good teams repeat this check after every major server update or role change. Regular checks ensure a fresh update does not reset your safe role rules.
Test: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does a safe test harm live mail flow?
No, a safe check only sends a harmless web request to inspect response headers. It does not change server files, drop mail queues, or stop active user sessions.
Why do patched servers still need role reviews?
A patch stops the login bypass, but it does not clean up old permissions. If an attacker steals a valid login, broad roles still let them export data.
What logs show if someone tried this attack before?
Web server logs show unusual requests sent to the client autodiscover path. Admin audit logs also record sudden role changes or new mailbox export tasks.