Anatomy of a Smishing Empire: Exploiting the Infrastructure Behind USPS Phishing

TLDR: This research breaks down the backend infrastructure of a massive SMS phishing campaign targeting USPS customers. By identifying a path traversal vulnerability and a blind, time-based SQL injection, the researcher successfully dumped the attacker's database, exposing thousands of victim records. The analysis provides a blueprint for how to deobfuscate malicious PHP code and highlights the operational security failures common in modern phishing kits.

Phishing is rarely just a simple landing page anymore. The "Smishing Triad" campaign, which has been hitting mobile devices with fake USPS delivery alerts for months, is a masterclass in how attackers build scalable, automated infrastructure. While most security teams focus on blocking the domains or flagging the SMS patterns, the real story is in the backend. This campaign isn't just a collection of random sites; it is a sophisticated, automated operation that relies on a centralized command-and-control structure.

Unmasking the Backend

The attack flow starts with a simple SMS containing a link. When a user clicks, they are directed to a site that looks identical to the official USPS tracking portal. The deception is effective because the site dynamically loads legitimate resources from the actual USPS website, making it appear authentic to the average user. However, the input fields on the page are designed to harvest PII and credit card data.

During the analysis, it became clear that the site was not just a static page. It was a functional web application. By using Burp Suite, I intercepted the traffic and noticed unusual WebSocket activity. There is no legitimate reason for a static tracking page to maintain a persistent WebSocket connection to a backend server. This was the first indicator of a C2 channel.

Exploiting the Infrastructure

The vulnerability that brought the whole house of cards down was a classic path traversal flaw. By manipulating the file parameters, I could read arbitrary files from the server. This led me to the access logs, which revealed the attacker's administrative panel.

The admin panel was built using PHP and MySQL. After gaining access, I discovered a blind, time-based SQL injection vulnerability. Because the application was blind, I couldn't just dump the database with a simple UNION SELECT. Instead, I had to rely on time-based inference. By injecting a payload that forced the server to pause execution, I could confirm the database structure bit by bit.

' AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)--

This technique is slow, but it is reliable. Once I confirmed the injection point, I was able to dump the entire admin table. The data was a goldmine: encrypted usernames, session tokens, and MD5-hashed passwords.

Deobfuscating the Malicious PHP

The attacker attempted to hide their tracks by heavily obfuscating the PHP source code. The code was essentially unreadable, using complex variable names and nested eval() calls to execute logic on the fly. Standard static analysis tools failed to make sense of it.

To bypass this, I used a technique called eval hooking. By modifying the PHP environment to intercept the string passed to the eval() function before it was executed, I could dump the raw, deobfuscated code to a log file. This revealed the attacker's hardcoded IP addresses and the specific logic used to process stolen credit card data. For those interested in the mechanics of this, the php-eval-hook project provides a solid implementation for testing this approach in a controlled environment.

The Operational Reality

The data I recovered was staggering. Over 1.2 million credit card entries had been processed through this specific infrastructure. The attackers were not just stealing data; they were managing it with the efficiency of a legitimate SaaS company. They had dashboards, statistics, and even automated alerts for when a new victim entered their data.

What makes this particularly dangerous is the "copy-cat" nature of these operations. Once a phishing kit is leaked or sold on a forum, it is modified and redeployed by dozens of different groups. The infrastructure I analyzed was being used by multiple actors, all sharing the same backend logic but using different front-end domains.

Defensive Takeaways

For defenders, the lesson is clear: stop looking at the front-end. The domain names will change every hour, but the backend infrastructure—the PHP scripts, the database schemas, and the C2 communication patterns—remains consistent. If you are a security researcher or a pentester, focus on identifying the unique fingerprints of these kits. Look for the WebSocket patterns and the specific error messages returned by the backend when you fuzz the input fields.

If you are on the blue team, implement strict egress filtering on your web servers. These phishing kits often need to communicate with external C2 servers to exfiltrate data. If your server is not supposed to be talking to a random IP in a foreign data center, block that traffic.

The Smishing Triad is just one example of a growing trend in automated, high-volume fraud. These attackers are using the same tools we use to secure our applications to compromise them. We need to start treating phishing infrastructure with the same level of technical scrutiny we apply to any other web application vulnerability. The next time you see a suspicious link, don't just report the URL. Dig into the headers, inspect the traffic, and find the backend. That is where the real fight is happening.