Misconfigured Python Server Exposes Three Active AiTM Phishing Campaigns

A misconfigured Python web server exposed files connected to three active adversary-in-the-middle phishing campaigns, giving researchers an unusual view into the attackers’ infrastructure and working methods.

The publicly accessible server contained phishing tools, campaign files, login-relay components, and a custom bulk email application called MaDoO Blaster. Attackers could use the collection to distribute lures, imitate legitimate sign-in pages, and capture authenticated sessions.

Researchers at Lexfo found the exposed service on a virtual private server. The incident appears to have resulted from an operational mistake rather than an exploited software vulnerability.

A simple Python server exposed the attackers’ files

Python includes lightweight HTTP server functions that make sharing files between systems easy. Developers and administrators often use them for temporary testing, transfers, and local development.

However, a server bound to a public network interface can expose its directory to anyone on the internet. Weak firewall rules or a forgotten process may leave files accessible long after the original task ends.

In this case, researchers could inspect materials that phishing operators normally keep behind authentication or network restrictions. The exposed directory reportedly connected one host to three ongoing campaigns.

Exposed component	Potential use
Phishing page files	Imitate trusted authentication portals
AiTM components	Relay sign-in traffic and capture session data
Configuration files	Define targets, domains, redirects, and campaign settings
Email templates	Create messages designed to direct victims to phishing pages
Bulk mailer	Distribute phishing messages to large recipient lists
Testing materials	Help operators check pages before launching campaigns

Three campaigns appeared on the same infrastructure

The exposed host contained material associated with three active phishing campaigns. That overlap gives investigators an opportunity to compare page templates, scripts, naming patterns, configurations, and other technical details.

However, one server does not automatically mean that a single threat group controlled every campaign. Criminal operators frequently share hosting, sell phishing kits, rent infrastructure, and provide campaign-management services to customers.

A developer or administrator may also manage technical resources on behalf of several clients. Investigators therefore need additional evidence before assigning all activity to one actor.

• One operator may have controlled all three campaigns.
• Separate attackers may have purchased the same phishing kit.
• A service provider may have managed campaigns for several customers.
• Multiple operators may have shared one virtual private server.
• An administrator may have reused tools and templates across projects.

AiTM phishing can capture authenticated sessions

Adversary-in-the-middle phishing places an attacker-controlled service between the victim and a legitimate authentication provider.

The fake page relays the victim’s username, password, and authentication requests to the real service. It then displays the legitimate response to the victim while recording valuable information from the exchange.

This technique can capture a valid session cookie or token after the victim completes multifactor authentication. The attacker may then reuse that session data to impersonate the user without repeating the original sign-in process.

1. The attacker sends a phishing email containing a sign-in link.
2. The victim opens an attacker-controlled login page.
3. The phishing server forwards the credentials to the legitimate service.
4. The real service requests an additional authentication factor.
5. The victim completes the MFA prompt through the phishing page.
6. The attacker relays the response and captures the resulting session.
7. The operator reuses the session to access the victim’s account.

Traditional MFA does not stop every phishing proxy

Multifactor authentication still blocks many password-based attacks. However, one-time codes, push approvals, and similar methods can remain vulnerable when an AiTM service relays the sign-in process in real time.

The victim may see a familiar login page and receive a genuine authentication request from the real provider. From the user’s perspective, the process can look like a normal login.

Phishing-resistant authentication offers stronger protection because it verifies the relationship between the authenticator and the legitimate website. The CISA guidance on phishing-resistant MFA recommends FIDO-based methods for stronger protection against credential phishing.

Authentication method	Relative resistance to AiTM phishing
Password only	Low
Password and SMS code	Limited protection against real-time relays
Password and authenticator code	Limited protection against real-time relays
Push notification	Can remain vulnerable to relays or approval manipulation
FIDO2 security key	Strong phishing resistance
Properly implemented passkey	Strong phishing resistance

The server contained a custom phishing mailer

The exposed files reportedly included MaDoO Blaster version 4.7.3, a custom bulk email tool associated with the operator.

A bulk mailer can automate the delivery of large numbers of phishing messages. It may provide options for importing recipient lists, changing sender information, selecting templates, and tracking delivery attempts.

Finding the tool alongside phishing pages and AiTM components gives researchers more context about the campaign workflow. The operator may have used the same infrastructure to prepare lures, send messages, host pages, and manage stolen information.

• Importing target email lists
• Selecting phishing message templates
• Changing sender names and addresses
• Managing subject lines and lure text
• Sending messages in batches
• Tracking errors or delivery status

Operational mistakes can reveal criminal infrastructure

Threat actors spend considerable effort hiding their identities and servers, but ordinary configuration errors can undermine those protections.

An exposed directory may reveal source code, internal file paths, account names, timestamps, email addresses, domain configurations, and revisions of phishing templates.

These details can help researchers connect campaigns that initially appear unrelated. They can also support infrastructure takedowns, detection rules, account suspensions, and notifications to targeted organizations.

Exposed data provides only a temporary intelligence window

Publicly accessible attacker infrastructure can disappear quickly. Operators may shut down the server, remove files, restrict access, or move the campaign after noticing outside attention.

Researchers must preserve relevant evidence carefully while avoiding changes that could disrupt an investigation or alert the attacker prematurely.

According to the Lexfo investigation, the exposed environment offered a view across multiple campaigns. Such visibility remains unusual because phishing administration systems normally sit behind restricted interfaces.

Small internet-facing services need security controls

The incident also highlights risks that affect legitimate organizations. A temporary Python server can expose confidential data just as easily as it can expose a phishing toolkit.

Development teams may start lightweight services to share builds, logs, configuration files, database exports, or test data. Without a defined shutdown process, those services can remain online indefinitely.

Organizations should include temporary servers in asset inventories, vulnerability reviews, firewall audits, and cloud-security monitoring. Their small size does not reduce the sensitivity of the files they may contain.

• Bind temporary services to localhost when public access is unnecessary.
• Restrict access through firewall rules or private networks.
• Require authentication for sensitive file repositories.
• Set automatic expiry dates for temporary virtual machines.
• Scan public IP ranges for unexpected listening services.
• Remove test files immediately after completing a project.
• Review cloud security groups after each deployment.
• Assign an owner to every internet-facing asset.

How defenders can detect AiTM phishing

Security teams should monitor both the initial phishing message and the account activity that follows a successful login.

A victim may authenticate from their normal device while an attacker reuses the captured session from another location shortly afterward. This can create abrupt changes in IP address, browser properties, device identity, or network provider.

Defenders should also inspect sign-ins that begin through unexpected links, newly registered domains, URL-shortening services, or redirects that place an unfamiliar host before the legitimate authentication page.

Detection area	Warning sign
Email	Unexpected sign-in links or urgent account warnings
Domain	Lookalike authentication hostname
Authentication	MFA request that the user did not initiate
Session	Rapid reuse from a different IP address or device
Account activity	New inbox rules, forwarding settings, or application consent
Cloud access	Downloads or administrative actions inconsistent with the user’s role

Session controls can limit damage

Organizations should not treat a successful MFA event as proof that the entire session remains trustworthy.

Conditional access policies can evaluate device compliance, network location, sign-in risk, and other signals before granting access to sensitive applications.

Shorter session lifetimes, continuous access evaluation, token binding, and rapid session revocation can reduce the time available to an attacker who steals session data.

• Require managed devices for sensitive applications.
• Use risk-based conditional access policies.
• Revoke active sessions after suspicious authentication.
• Monitor new application consent and mailbox rules.
• Limit persistent browser sessions for privileged accounts.
• Require stronger authentication for administrative actions.
• Review access from anonymizing services and unfamiliar networks.

Phishing-resistant MFA offers stronger protection

FIDO2 security keys and passkeys use cryptographic authentication tied to the legitimate website. A phishing proxy operating on another domain cannot normally use the authentication response for the real service.

Organizations should prioritize phishing-resistant methods for administrators, finance teams, executives, developers, and employees with access to sensitive information.

The second reference to CISA’s phishing-resistant MFA recommendations explains why FIDO authentication provides stronger protection than passwords combined with one-time codes.

Users should inspect sign-in links carefully

Employees should avoid signing in through unexpected email links, even when the message uses a familiar company logo or creates a sense of urgency.

Opening a known bookmark or typing the organization’s official address directly into the browser reduces the chance of visiting an attacker-controlled proxy.

Users should report unexpected authentication prompts immediately. A prompt can indicate that someone has already entered the user’s password or started relaying a login attempt.

1. Do not open unexpected account-verification links.
2. Use a saved bookmark for important sign-in portals.
3. Check the complete domain before entering credentials.
4. Reject MFA prompts that you did not initiate.
5. Report suspicious messages through the approved security channel.
6. Change exposed credentials and request session revocation after a suspected incident.

Organizations should inventory temporary systems

The exposed server demonstrates how one forgotten service can reveal far more than its operator intended.

For attackers, the mistake exposed tools and campaign connections. For legitimate businesses, the same error could reveal source code, customer data, credentials, internal documents, or cloud configuration files.

Every public service should have an owner, a documented purpose, access restrictions, monitoring, and a planned removal date. Security teams should regularly compare internet-facing assets with their approved inventory.

The discovery does not confirm one attacker controlled everything

The presence of three campaigns on one host provides a valuable investigative link, but defenders should separate infrastructure overlap from confirmed attribution.

Shared kits, criminal service providers, and rented servers can create technical similarities between unrelated operators. Investigators need account records, payment data, login history, communication evidence, or consistent operational behavior to make stronger conclusions.

The exposed Python server still provides meaningful intelligence. It shows how attackers organize AiTM phishing activity and how one configuration mistake can uncover relationships that ordinary phishing reports may miss.

FAQ