The first time on the other side0
For the past few years, my work has been defensive: I have written detection rules in Sentinel, hardened Conditional Access, and reviewed sign-in logs for anything that looked unusual. Consequently, I usually understood attacks from the outside looking in. I saw the outcome, the alert, and the evidence, but almost never the person initiating the action.
This week, I was the one initiating the action. In a completely isolated lab under my control, I built a phishing attack with Evilginx against a Microsoft test account that belonged to me. I wanted to answer a straightforward but uncomfortable question: just how difficult is the attack I spend my days working to stop?
The answer was considerably less difficult than I would have preferred.
What an AiTM actually is
Before getting into the phases, one common misconception needs to be addressed. Many people imagine phishing as an obviously fake login page, perhaps a poorly made clone accompanied by a suspicious URL that would immediately stand out. Evilginx belongs to a different category.
It operates as a reverse proxy positioned between the victim and the legitimate service. Once the victim follows the link, the response is not simply a copy: the actual Microsoft login page is relayed through the attacker. The victim enters the credential into the genuine interface, padlock and all, while the intermediary positioned within the flow can read what passes through.
That intermediary position is what gives the technique its name: Adversary-in-the-Middle (AiTM). It is among the most effective forms of phishing today because it removes many of the warning signs that users are taught to recognize.
What I built (from above)
There is no step-by-step recipe here; this is a case study, which is why some screenshots have been censored.
The Docker installation was completed, and I cloned the git repository.
Next, I worked out how to install a phishlet and found one to use.
I then created the config file.
Afterward, I created a certificate, moved it into the correct folder, and assigned the required permissions.
I installed make and Go.
Then I built it.
I created the log folder, validated the certificate, and started evilginx.
I made a small correction to stop the error on port 53 and created a new phishlet called o365.
Configured the hostname for the phishlet
Enabled it
Then I created a lure for o365:
Once I used the generated URL, my access appeared in the environment.
After completing the login, I was able to capture the account’s username and password.
What really impressed me
It was not the sophistication of the attack. Instead, what stood out was how low the barrier to entry was.
I had expected considerably more friction. I assumed I would spend hours tuning the setup, working through configuration issues, and encountering one error after another. Some of that happened, but far less than I expected given the impact of the attack. With average technical ability and a few hours of patience, someone can reach the same point I did.
That changes the broader picture. If an attack with this level of impact, capable of capturing credentials for a critical corporate service such as Microsoft 365, is accessible to anyone with enough time and curiosity, the question is no longer “will someone try?” Instead, it becomes “how many times a week is this already knocking on my company’s door?”
AiTM is not merely conference theory. It is a commodity.
Why this matters for defenders
Working from the offensive side changed how much weight I place on things I already “knew” in theory.
Seeing the genuine Microsoft screen appear through my own proxy showed me in practice why telling users to “check the URL” is, by itself, a fragile defense. What truly changes the situation against AiTM is the authentication architecture: methods that bind the login to the legitimate origin and prevent an intermediary from impersonating the victim.
That is a discussion for another post. For this one, the conclusion is more direct and more uncomfortable: I built from scratch an attack that I spend my days recommending companies defend against, and the difficult part proved far easier than I had expected.
The test took place in an isolated lab against an account I own, with no real target involved. The purpose was to understand the attack so that it could be defended against more effectively.