Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to replace phishing domain in certain edge cases #1111

Open
ziggoon opened this issue Sep 20, 2024 · 0 comments
Open

Failure to replace phishing domain in certain edge cases #1111

ziggoon opened this issue Sep 20, 2024 · 0 comments

Comments

@ziggoon
Copy link

ziggoon commented Sep 20, 2024

Summary:
Evilginx is not replacing the phishing domain in certain GET requests and Location headers in responses.

While preparing a phishlet for an upcoming engagement I noticed that an ADFS authentication service was complaining about bad requests coming from evilginx, thus failing to initiate the authentication process. After sending the traffic through Burp I saw a request from the evilginx server to the auth service with the phishing domain in one of the URL parameters.

Bad request: GET /api/Account/Login?returnUrl=https%3A%2F%2Fsubdomain.ziggoon.local%2F

I was able to "patch" this with Burp by using an HTTP match and replace rule which replaced "ziggoon.local" in request headers with the target domain. This allowed me to reach the ADFS login page and enter creds, but I was not receiving an MFA prompt. I added my browser to the proxy and checked the Burp logs again and noticed a response from evilginx the had the legitimate domain in the Location header, which was causing the auth flow to break. Again, was able to "patch" this with Burp and I successfully captured creds and tokens in evilginx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant