In January we launched new functionality for Attic to detect AiTM attacks targeting the Microsoft 365 tenant of customers. Using the platform of didsomeoneclone.me and custom CSS in the Microsoft login page. Since then we are monitoring new detections and obviously, as security researchers, we deepdive into any detection that involves previously unseen TTPs.
Our detection system discovered a couple of detection on the workers.dev domain. This domain, is related to the Cloudflare Workers. We find this interesting: how is the actor abusing Cloudflare Workers?
What is a Cloudflare Worker
A Cloudflare Worker is essentially a script running in the Cloud. Sometimes also called a Serverless Function. Using Serverless Functions is useful, because you do not have to maintain the servers and/or worry about scalability. In this case, Cloudflare will handle this for you. You only have to worry about the code. Most providers even offer the functionality for free. You just need a Cloudflare account.
Identifying the phish
So, we detected a couple of phishes using a workers.dev domain. Some of them were unreachable, because we did not have the full path of the attack yet. However: later on, we detected a legitimate attack on one of the clients. A real victim was logging into the page. This revealed the full path to us. We were able to access the phishing page:
Reproducing the attack
We do not have access to the code of the Cloudflare Worker. Therefor, we need to create a Worker ourselves, trying to reproduce the attack. We first searched online for any Cloudflare Worker reverse proxy implementation, and found this one, a good starting point: https://gist.github.com/douglarek/33d653cf09cd6d80df2e9dc561b19079
We uploaded the code to a Cloudflare Worker. We changed the reverse proxy domain to login.microsoftonline.com. Using trial and error, we still needed to do some changes to the implementation. We had to replace a couple of login.microsoftonline.com links in the response. Also, the domain login.microsoftonline.com defined on the cookies have be replaced with our workers.dev domain.
Next we added a Teams notification feature. This allows us to send the username, password and collected cookies to a Teams channel. This information is enough for an attacker to take over the Microsoft account.
This image shows a simplified flow of the process:
Done! Our proof of concept works. The code is available here. This was surprisingly simple.
Video
The attack:
Conclusion
We detected a, to us, previously unknown attack. With only 174 lines of code we were able to create a full fledged AITM attack on Microsoft tenants. Bypassing MFA and obtaining access to Microsoft accounts.
Be aware that this proofs that AITM attacks are pretty simple. This attack may be reproduced in any other Serverless Function provider and/or language. The fact that it is this simple also shows that it is important to implement mitigations to prevent these kind of attacks. Currently the following mitigations are common to prevent AITM attacks:
- Only allow compliant devices to access Microsoft 365 using a conditional access policy
- Implement AITM resistant MFA solutions such as FIDO2, Windows Hello or Certificates
Of course, it’s not always that easy to implement above mitigations in existing organizations, but at least consider it. Another option is to implement our detection, this example shows how effectively it detects AITM attacks.
Also fun: I never wrote NodeJS before, neither worked with Cloudflare Workers. So learned new stuff. Hate NodeJS and love Cloudflare Workers 😀