Introduction Most cybersecurity investigations start with an alert. This one started with curiosity. While scrolling through X (formerly Twitter), I came across a post discussing a suspicious website that appeared to be distributing software downloads. At first glance, it looked like another fake download portal. But after spending several hours investigating it, I found myself doing something I never expected: I accidentally logged into the threat actor’s dashboard. This article documents the investigation, infrastructure analysis and lessons learned from interacting with a live threat actor website. Discovery on X While scrolling through X, I came across a cyber intelligence post that appeared in my feed. Since I follow several professionals in the cybersecurity and threat intelligence community, my timeline frequently recommends content related to cyber threats, malware analysis and indicators of compromise (IOCs). As part of my routine, I review these posts and analyze any IOCs that are shared. If I identify relevant indicators, I add them to our security environment for further investigation and detection purposes. In this particular case, the post attracted my attention because of its engaging visual presentation and clear delivery of threat intelligence. Without conducting a deeper validation at first, I extracted the IOC and investigated the associated domain. During the analysis, I discovered that the domain was still active and likely Vibecoded. Curiosity Took Over Instead of stopping at surface-level analysis, I started enumerating the web application. Directory brute forcing quickly revealed something interesting: /admin/login.php /config/database.php /install/install.php The directory enumeration performed with ffuf revealed several interesting paths, but /install/install.php stood out immediately. Although the application was already deployed and actively serving content, the installation page remained accessible. This raised an obvious question: was the installer properly locked after deployment? To answer that, I decided to try my luck and attempt a reinstallation. Before proceeding, however, I needed to understand the application’s setup process and gather the required information to avoid breaking the existing deployment. Setup MySQL Instance and Took Over the DB Based on the directories discovered with ffuf, I took a closer look at the installation page. The form was asking for a MySQL database connection, which looked exactly like the onboarding process used when the application is first deployed. Curious to see what would happen, I spun up a MySQL instance in Docker and exposed it so the target application could reach it. After filling in the required fields, I submitted the installation process and, to my surprise, it completed successfully. That was the first sign something was wrong. Even though the application was already running in production, there was nothing preventing the installer from being executed again. There were no checks to verify whether the application had already been initialized. As part of the setup process, I was asked to create the initial administrator account. Once the installation finished, I checked my MySQL instance and saw the application creating its tables and populating the database schema. At that point, the application was connected to infrastructure I controlled and I had valid administrative credentials created through the installation workflow itself. Something strange happened after the installation completed. I was able to log in with the administrator credentials I had just created, but the dashboard immediately returned a 500 Internal Server Error. My initial assumption was that there was a synchronization issue between the database and the application files on the server. The installation process had succeeded, but something clearly wasn’t lining up correctly on the backend. Since I couldn’t access the dashboard properly, I eventually shut down my ngrok tunnel and MySQL instance. Shortly after, the domain itself started returning 500 errors, likely because the application was still trying to connect to the database instance I had provided during the reinstallation process. Read also: Hacking Phishing-as-a-Service The Dashboard Suddenly Loaded After taking a break, I checked the domain again and noticed it was back online. The threat actor had clearly fixed the database issue and restored the application. I opened my last tab that shown 500 error again and refresh the page. To my surprise, the dashboard loaded successfully this time. Then I remembered something important: this was a PHP application. My previous login session was still valid. The application appeared to store session state on the server rather than in the database, so even though the backend had been reconfigured, my session cookie was still recognized. I sent the same session token and the application simply responded as if nothing had happened. No re-authentication, no session ...