Support portal abuse (osTicket)

Support ticketing systems like osTicket (PHP + MySQL, widespread in companies, universities and governments) are rarely vulnerable to a CVE, but their legitimate functionality is enough to gain a foothold. Two abuses stand out: opening a ticket assigns an internal domain email address usable to register on other company services; and the agent panel, if we reuse leaked credentials, lets us read conversations where support sends reset passwords in the clear. It is not a code flaw, it is design misused.

Mechanism

First identify the instance: the OSTSESSID cookie, the "powered by osTicket" footer or a "Support Ticket System" label give the application away even when Nmap only shows Apache or IIS. When opening a ticket at /open.php, the system assigns a number and an internal email address like:

940288@<domain>

If the helpdesk correlates ticket numbers with email, any message sent to that address shows up in the ticket. With that "company" address we can register on external portals (GitLab, wikis, chats) that require a corporate email and receive the verification mail in the ticket itself.

The second abuse targets the agent panel (/scp/login.php). With credentials leaked via OSINT (for example, a Dehashed dump), we try username and password; it is worth also trying the email as the login identifier, not just the username:

username: kevin           -> fails
email:    kevin@<domain>  -> access granted

Inside, closed tickets often hold gold: an agent resetting an employee's VPN and sending them the standard new-employee password through the portal. That password is reused against the VPN or fired in a spray against other users.

Requirements

Access to the support portal (often exposed externally) and, for the agent panel, prior credentials (leaks, OSINT, reuse). The first abuse needs no credentials: being able to open a ticket is enough. The value depends on whether the organization reuses passwords and whether the portal is reachable from outside.

How to detect it. The abuse is given away by tickets created with odd contact details followed by using the assigned address to register on other services, agent-panel logins from external IPs or inactive accounts, and bulk reading of closed tickets. On external portals, a registration verified with a helpdesk NNN@domain email is a clear hint.

Defence. Limit which applications are exposed to the Internet, require MFA on all portals, train employees not to use corporate email on third-party services, enforce a strong password policy in AD and in the applications, and force a password change after first login. It fits credential reuse, password spraying, email-based user enumeration and username enumeration.