AiTM Lab Setup: Preparing the Phishing Club Test Environment

October 9, 2026

Objective

Before starting the AiTM Fundamentals labs, I prepared a dedicated test environment for exploring authentication flows, browser behavior, and session management in Phishing Club.

The goal was to establish a reusable laboratory environment, document its components, and understand how local name resolution and browser isolation affect testing. This preparation provides the foundation for the upcoming labs without requiring the environment to be rebuilt for every experiment.

Lab Environment

Hypervisor: VMware Workstation Pro
Operating system: Kali Linux
Lab platform: Phishing Club
Browser: Brave
Browser profiles: Separate profiles for isolated testing contexts
Local name resolution: dnsmasq
Lab domain namespace: .pclabs

Phishing Club was running locally, with its process listening on ports 80, 443, and 40795. The administrative interface was accessible through the lab's local network configuration.

Experiment

1. Preparing the browser environment

Brave was selected as the dedicated browser for the lab. Separate browser profiles were created to keep testing contexts independent and reduce interference from existing cookies, authentication state, and browsing data.

This separation also makes it easier to reproduce experiments and compare browser behavior.

Why it matters: Browser profiles maintain separate browsing state. However, profile separation alone does not guarantee complete isolation of the underlying operating system or network.

2. Planning local DNS resolution

The lab contains multiple fictional domains. Managing every hostname individually would make the environment harder to maintain, so I explored local DNS resolution using dnsmasq.

The intended namespace was .pclabs, allowing lab hostnames to be distinguished from ordinary internet domains.

A local resolver can provide predictable name resolution for a controlled test environment. It can also forward queries for other domains to an upstream DNS resolver.

3. Verifying name resolution

I used basic connectivity checks to verify the behavior of local and external hostnames.

The results showed that:

foocorp.pclabs resolved to the local loopback address, 127.0.0.1.
google.com resolved to an external IP address and responded to the connectivity test.
Both tests completed without packet loss in the captured output.

These observations confirmed that local name resolution and external connectivity were working at the time of testing.

Important distinction: A successful ping confirms that the destination responds to ICMP. It does not prove that an HTTP service is available, that TLS is configured correctly, or that an application is functioning.

Technical Analysis

Why local DNS is useful

Local DNS makes a multi-domain lab easier to maintain than a collection of manually managed hostname entries.

It also provides a useful opportunity to study the difference between:

DNS resolution: mapping a hostname to an IP address;
Network connectivity: determining whether a destination responds;
Application availability: determining whether a service handles a request;
TLS validation: determining whether a certificate is trusted and matches the hostname.

These are separate layers. Success at one layer does not automatically imply success at the others.

Why the lab namespace matters

A dedicated namespace makes fictional lab hosts easier to recognize and helps reduce accidental confusion with real services.

The .local namespace can interact with multicast DNS (mDNS) conventions, so a dedicated lab namespace can be easier to reason about in a controlled environment. The choice of namespace should still be documented and tested against the resolver behavior of the operating system.

Why browser isolation matters

Authentication experiments depend on browser state. Cookies, cached responses, active sessions, and stored site data can affect the results.

Using separate profiles helps make experiments repeatable, but sensitive authentication material must still be handled carefully. Session cookies should be treated as credentials because possession of a valid session token may grant access to an authenticated session.

What I Learned

A successful ping is not a complete service test. Application requests and TLS validation need separate checks.
Browser state affects reproducibility. Separate profiles help prevent unrelated sessions and stored data from influencing an experiment.
Reusable lab infrastructure needs documentation. Recording the environment and its verified behavior makes later experiments easier to reproduce.

Defensive Takeaways

Monitor unusual DNS patterns

Organizations can use DNS telemetry to investigate unusual hostname patterns, unexpected subdomains, and lookalike domains associated with authentication services.

Use phishing-resistant authentication

FIDO2/WebAuthn-based authentication can provide stronger protection against adversary-in-the-middle phishing than methods that rely solely on passwords or one-time codes.

Treat session cookies as sensitive credentials

HttpOnly, Secure, and SameSite are useful cookie protections, but they do not independently prevent every form of session theft. Organizations should combine secure cookie settings with phishing-resistant authentication, session lifecycle controls, and monitoring for suspicious sign-in activity.

Keep browser security enabled outside controlled testing

Browser reputation checks and phishing protections are important defensive controls. Any changes made for a laboratory experiment should remain confined to that environment and should not become the default configuration for everyday browsing.

Conclusion

This preparation established the baseline for the Phishing Club lab series and clarified the roles of local DNS, browser state, network connectivity, and application listeners.

The next stage will focus on individual authentication-flow experiments, recording verified behavior and translating the observations into practical defensive lessons.

Page updated

Google Sites

Report abuse