A basic server configuration mistake has revealed the tools, credentials and operational methods behind three separate phishing actors using Evilginx and related adversary-in-the-middle techniques. The exposure originated from a virtual private server in Budapest that had been running a simple Python HTTP service with directory listing enabled. Because the server was left publicly accessible, anyone who found it could browse and download files stored inside.
Those files reportedly included phishing configurations, captured credentials, remote-access installers, bulk-emailing tools and even Telegram session data belonging to one of the operators. What began as an open directory ultimately provided a detailed look at how modern phishing campaigns are assembled, maintained and expanded.
A Complete Phishing Toolkit Left Exposed
The main operator linked to the server was known online as codemado.
The actor was using an Evilginx-based adversary-in-the-middle platform to target corporate Microsoft 365 accounts. Evilginx does not simply imitate a login page and collect passwords. It sits between the victim and the legitimate service, forwarding traffic while intercepting authentication details and session cookies.
This distinction is important because session-cookie theft can allow attackers to bypass some forms of multi-factor authentication. Even when a victim enters a valid one-time code, the attacker may still capture the authenticated session created after the verification process.
The exposed directory contained much more than phishing templates. It also included credential logs, management utilities and operational files that appeared to document how the infrastructure was being controlled.
Remote Management Tools Supported Longer-Term Access
The server contained several remote monitoring and management tools, including ScreenConnect and SimpleHelp.
Although these applications have legitimate business uses, attackers often abuse them to establish persistent remote access after compromising a device or account.
The presence of multiple remote-management installers suggests that the phishing operation was not always limited to stealing credentials. In some cases, the attackers may have attempted to move beyond account access by installing software that allowed them to control compromised systems more directly.
The collection reportedly contained seven separate remote-management tools, giving the operator several alternatives if one product was blocked or detected.
The server also hosted a custom bulk-emailing application known as MaDoO Blaster. This tool appeared to have been created by codemado and was likely used to distribute phishing messages at scale.
Custom mailers allow attackers to control message templates, recipient lists, sender identities and campaign timing without relying entirely on commercial marketing platforms.
Three Operators Connected Through Shared Code
The exposed files also led investigators to two other actors: mail-argenta and saroula01.
Their connection was primarily technical. Codemado had copied or cloned Evilginx-related repositories associated with the other two operators.
That does not necessarily mean the three actors worked together. Public code repositories can be downloaded by anyone, and phishing developers frequently reuse or modify tools created by others.
However, the shared code lineage shows how quickly techniques can move between different criminal operations. One developer can publish a phishing framework, another can customise it and a third can integrate it into a broader campaign.
This pattern makes it increasingly difficult to separate organised collaboration from independent criminals using the same publicly available building blocks.
Reused Credentials Exposed One Operator
The identity trail around mail-argenta reportedly began with infostealer data containing credentials the actor had reused.
One of the strongest clues was a MySQL password hardcoded into a phishing administration panel. Reusing passwords across personal accounts, development systems and criminal infrastructure created a link that could be followed back to a suspected Nigerian individual.
The incident highlights an irony often seen in cybercrime investigations. Threat actors exploit poor password practices among their victims while making many of the same mistakes themselves.
Hardcoded credentials are especially risky because they may remain visible in source-code repositories, backups and older versions of software long after the password was originally created.
Device Code Flow Abuse Created a Different Kind of Phishing Attack
The third operator, saroula01, developed a framework that abused Microsoft's OAuth Device Code Flow.
Device Code Flow is a legitimate authentication method designed for devices or applications that may not have a convenient keyboard or browser. A user is shown a short code and instructed to enter it on an official Microsoft authentication page.
Attackers abuse this process by persuading victims to enter a code generated for the attacker's session.
Unlike a traditional fake login page, the victim may actually be interacting with a genuine Microsoft website. This makes the attack more convincing because the domain, security certificate and login interface all appear legitimate.
Once the victim completes the authentication, the attacker's backend receives the resulting access token.
This method can bypass many of the warning signs users are trained to recognise because there may be no obvious fake website involved.
The Largest Campaign Operated for More Than a Year
Saroula01's operation appeared to be the most extensive of the three.
Investigators reconstructed a deleted configuration file from repository history and used internal bot timestamps to trace the campaign back to June 2025.
The recovered data suggested that the operation had continued for more than a year without a major interruption.
During that period, the campaign accumulated 218 confirmed victims across 12 countries. Approximately 94% of the affected accounts belonged to organisations, showing that corporate users were the primary targets.
The attackers were not merely capturing one-time access. Tokens were configured to refresh automatically, allowing sessions to remain active in the background.
Some recovered records showed that access tokens had been silently refreshed as many as 25 times.
This meant the attackers could potentially retain access long after the victim had forgotten the original phishing interaction.
Session Persistence Makes Token Theft Especially Dangerous
Traditional password theft can sometimes be addressed by resetting the compromised password.
Token theft creates a more complicated situation.
An active session may continue working even after the password has changed, depending on how the account and application are configured. Attackers may therefore remain connected until the relevant sessions, refresh tokens and application permissions are explicitly revoked.
This is why organisations responding to adversary-in-the-middle phishing should not rely on password resets alone.
They may also need to revoke all active sessions, review OAuth application consent, examine device registrations, reset authentication methods and investigate suspicious mailbox rules or forwarding configurations.
For Microsoft 365 environments, reviewing identity logs and token activity is essential because the attacker may never log in using the password directly after the initial compromise.
Generative AI Is Reducing the Development Barrier
Another pattern across the exposed repositories was the apparent use of generative AI during development.
AI co-author metadata appeared in commits associated with saroula01, while a saved development session was reportedly found in mail-argenta's repository.
This suggests that the actors may have used AI assistants to write code, debug scripts or create supporting components.
Generative AI does not automatically turn an inexperienced person into a sophisticated attacker. However, it can reduce the amount of time required to produce working code, troubleshoot errors and customise existing phishing frameworks.
Tasks that once required stronger development knowledge can now be accelerated through natural-language prompts and automated code suggestions.
When combined with freely available phishing frameworks, stolen credentials and paid services promoted through Telegram, the barrier to operating a functional campaign becomes much lower.
Phishing-as-a-Service Expands the Reach of These Tools
Codemado's MaDoO Blaster was also associated with a wider phishing-as-a-service ecosystem known as The Quarry.
The service was promoted by an actor using the name RockyBelling, who reportedly offered the bulk-mailing tool to customers.
Phishing-as-a-service platforms operate in a similar way to legitimate software businesses. Customers may pay for templates, hosting, sending tools, technical support or access to preconfigured phishing infrastructure.
This business model allows people with limited technical skills to launch campaigns using tools created by more experienced developers.
Instead of building every component from scratch, an operator can purchase access to a phishing kit, rent infrastructure and begin sending messages within a relatively short time.
This also creates a layered ecosystem in which developers, infrastructure providers, access brokers and campaign operators may all be different people.
Multi-Factor Authentication Alone Is No Longer Enough
The exposed operation reinforces an increasingly important lesson: multi-factor authentication is essential, but not every form of MFA provides the same level of protection.
Adversary-in-the-middle platforms can intercept authenticated sessions after a user completes an MFA challenge. Device Code Flow abuse can trick users into authorising a session through a legitimate Microsoft page.
Organisations should therefore combine MFA with stronger controls such as phishing-resistant authentication, conditional-access policies, device compliance requirements and continuous session monitoring.
Hardware-backed security keys and passkeys can provide stronger protection than one-time codes or push notifications because they are tied more closely to the legitimate website and authentication session.
Push-notification fatigue should also be addressed. Users should never approve an authentication request they did not initiate.
Device Code Authentication Should Be Restricted
Device Code Flow may be necessary for certain devices and operational scenarios, but it should not remain enabled across an organisation by default when there is no business requirement.
Security teams should identify which users and applications genuinely need device-code authentication and block or restrict it elsewhere.
Conditional-access policies can also limit authentication based on location, device state, risk level and application type.
Organisations should monitor for unusual device-code activity, especially repeated code-generation events, sign-ins from unfamiliar locations and token use that does not match the user's normal behaviour.
Users should also be trained to recognise that being directed to an official Microsoft page does not automatically make a request safe. The critical question is whether they personally initiated the authentication process and understand which application is requesting access.
The Open Directory Was a Failure of Basic Security Hygiene
Despite the sophistication of some of the phishing techniques, the exposure itself resulted from a simple operational mistake.
Running a web server with directory listing enabled allowed outsiders to inspect sensitive files that should never have been publicly accessible.
The same type of error affects legitimate organisations as well. Backup archives, configuration files, API keys, credentials and internal documents are frequently exposed through misconfigured storage or temporary development servers.
The incident demonstrates that advanced attackers are not immune to basic security failures. Strong tooling and successful campaigns can still be undermined by poor server configuration, credential reuse and careless repository management.
Final Thoughts
The exposed server offered an unusually detailed view of how modern phishing operations are built from shared code, remote-management tools, bulk-emailing platforms and token-stealing techniques.
It also showed that these operations do not always involve highly organised teams. Independent actors can reuse the same Evilginx forks, purchase supporting tools and use generative AI to fill gaps in their technical knowledge.
For defenders, the main lesson is that passwords and conventional MFA can no longer be treated as the final security boundary.
Organisations should assume that attackers may attempt to steal authenticated sessions, abuse OAuth workflows and maintain access through automatically refreshed tokens. Phishing-resistant authentication, session revocation, stronger conditional-access controls and restrictions on Device Code Flow are becoming increasingly important.
At the same time, the incident is a reminder that basic security hygiene still matters. A single exposed directory was enough to reveal an entire collection of phishing tools, identities and campaign records—showing that even experienced threat actors can be undone by a simple configuration mistake.
Comments